Cryptographic Discovery and Remediation for Critical Infrastructure and Defense

Short answer: Cryptographic discovery in critical infrastructure and defense requires an inventory that reaches operational technology (OT), air-gapped, and sovereign environments; maps every quantum-vulnerable system to the data it protects and how long that data must stay secret; and sequences remediation by mission consequence rather than by ease of fix. Standard enterprise discovery tooling will not get you there.

Key takeaways:

• Discovery must cover three zones: enterprise systems, OT and fielded devices, and air-gapped or sovereign environments.
• Classify public-key algorithms built on factoring or discrete logarithms as quantum-vulnerable, and validate entropy as part of classification.
• Prioritize remediation by data lifetime, mission consequence, and exposure. Most organizations start with 10 to 20 systems.
• Where an OT asset cannot be migrated, compensate with segmentation and crypto-agile mediation, and log it in an exception register.

Why cryptographic discovery is harder in critical infrastructure and defense

Every large organization has a cryptography problem. Critical infrastructure and defense organizations face four extra constraints that change the answer.

1. Long asset life. A transformer, a combat system, or an industrial controller may run for 20 to 40 years. The cryptography inside it was chosen before quantum risk was a planning item and may not be replaceable on any timeline the business controls.
2. Physical consequence. In enterprise information technology (IT), a cryptographic failure is a breach. In OT, a cryptographic failure can be a safety event or a mission failure. Integrity of sensor and command data can matter more than confidentiality.
3. Restricted environments. Air-gapped networks, classified enclaves, and sovereign infrastructure limit what discovery tooling can reach and how findings can be exported.
4. Mandate pressure from two directions. Civilian timelines and national security timelines are not the same. National Institute of Standards and Technology (NIST) IR 8547 sets the civilian standard: deprecate quantum-vulnerable algorithms by 2030 and disallow them by 2035, with high-risk systems moving earlier. National security systems follow the National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), which requires exclusive use of quantum-resistant algorithms as early as 2030 for some system categories. Programs that plan to civilian deadlines will miss their own.

The combination means the standard enterprise playbook of scanning the data center, exporting a spreadsheet, and prioritizing by patch effort produces a plan that cannot be executed.

Part 1: Crypto asset discovery across three technical zones

Treat the estate as three zones with different discovery mechanics. A platform that handles only one of them will leave the highest-consequence exposure unmapped.

Zone A: Enterprise and corporate IT

The most tractable zone. Look for application crypto libraries, internal public key infrastructure (PKI) and certificate authorities, hardware security modules (HSMs), database encryption, secrets stores, service-to-service authentication, and hard-coded keys in application code.

The recurring miss is application-layer cryptography that no infrastructure scan will see. Include code-level analysis, not just network discovery.

Zone B: OT, industrial control systems (ICS), and fielded devices

This is where most quantum-readiness programs are weakest.

Look for device certificates, proprietary protocol cryptography, firmware and secure-boot signing, and the integrity mechanisms protecting sensor and command traffic. Expect to find:

• Devices that cannot be patched
• Devices installed in locations that are difficult or unsafe to service
• Devices using protocols that have never been brought to modern cryptographic standards
• Devices that are internet-connected for convenience and now represent an entry path into control networks

The realistic OT cryptography migration strategy for a large share of this zone is not migration at all. It is compensation: network segmentation, protocol gateways, and crypto-agile mediation layers that protect the device without changing it. Decide that explicitly rather than discovering it during execution.

Zone C: Air-gapped, classified, and sovereign environments

Discovery here requires tooling designed for it. Confirm three things before you commit to a platform:

1. Collection without outbound connectivity: How does the tool operate with no path to the internet?
2. Controlled export: How do findings move across the boundary without violating classification or policy?
3. Sovereignty: Where does data live, who can access it, and does the deployment satisfy national sovereign cryptography requirements?

If a vendor cannot answer all three concretely, the classified estate will be excluded from your program by default. That is usually where the most sensitive long-lifetime data sits.

Part 2: How to map quantum-vulnerable systems

Once assets are found, classification is mechanical and consistent.

Quantum-vulnerable: Rivest-Shamir-Adleman (RSA), Diffie-Hellman, Elliptic Curve Digital Signature Algorithm (ECDSA), and Elliptic Curve Diffie-Hellman (ECDH), including anything resting on integer factorization or discrete logarithms. This covers most key exchange, most digital signatures, and most certificate infrastructure in service today.

Weakened but viable: symmetric encryption and hashing. Grover's algorithm reduces effective security strength, so double the key length. The Advanced Encryption Standard with 256-bit keys (AES-256) and Secure Hash Algorithm 384 (SHA-384) remain appropriate.

The layer most inventories miss: entropy. A post-quantum algorithm is only as strong as the randomness feeding it. Predictable entropy breaks key generation, tokenization, and signature schemes no matter which algorithm is layered on top. Validate the entropy source as part of classification. In defense and infrastructure environments, this is often the finding that explains prior incidents.

Migration-resistant: some assets cannot be migrated and must be compensated for. Name them explicitly and assign them a compensating control, or they will quietly become permanent accepted risk.

For each vulnerable asset, record the same fields as an enterprise inventory (algorithm, location, owner, protected data, data lifetime, dependency, rotation mechanism) plus two that matter more here:

• Mission consequence: Which operational capability degrades or fails
•  Adversary value: How much a state-level actor would pay for this data

Part 3: How to prioritize post-quantum remediation

Prioritize on three axes. Rank every vulnerable system high, medium, or low on each.

Systems scoring high across all three axes should start immediately. Systems scoring high on lifetime and exposure but low on consequence still move early, because the data being captured today cannot be re-protected later.

The Harvest Now, Decrypt Later (HNDL) dynamic is the reason data lifetime outranks nearly everything else. Traffic captured in 2026 and decrypted in 2036 was never protected, regardless of what the plan said.

A practical shortlist for most organizations: long-lifetime records, command and control links, identity and PKI roots, and any system bridging IT and OT. That is typically 10 to 20 systems, not thousands.

Part 4: How to sequence remediation

Four options exist for every vulnerable system. Choose deliberately.

Sequence in this order:

1. Establish crypto-agility first. The ability to swap algorithms without redesign is worth more than any single migration. It converts a one-time project into an operating capability.
2. Migrate identity and PKI roots early. Nothing downstream can be quantum-safe until trust anchors are.
3. Migrate long-lifetime data protection next. This is an irreversible exposure.
4. Compensate the un-migratable. Segment, mediate, and document.
5. Verify continuously. Confirm the algorithm actually in use, not the algorithm in the plan.

Step five is where programs quietly fail. A system configured for post-quantum cryptography (PQC) that negotiates a legacy fallback looks migrated on a dashboard and is not migrated in practice.

Part 5: Evidence, governance, and assurance

In this sector, a plan is not sufficient. You need proof.

Build an evidence pack that travels with the program and can be produced on demand:

• Systems and zones covered by discovery, with scope exclusions stated
• Algorithms in use, by system and by data class
• Certificate and key handling posture
• Entropy source validation and test results
• Migration status by system, with verification method
• Compensating controls for un-migratable assets
• Exception register with owners and review dates

Assign accountability explicitly. One owner for the inventory, one for migration execution, one for exceptions. Unassigned cryptography becomes unmanaged cryptography.

Report to leadership quarterly on four numbers: assets discovered, assets classified, assets migrated and verified, and exceptions open. Those four numbers are the program.

‍

How enQase fits

enQase is built for environments where the standard enterprise stack does not reach. Discovery and remediation run through a single governable path spanning encryption, key management, entropy, and hardware-rooted trust. This includes quantum-native sources whose security rests on physics rather than computational assumptions.

For critical infrastructure and defense programs, the relevant distinction is coverage: discovery that reaches OT, restricted, and sovereign environments, and a remediation path that does not require assembling and coordinating a multi-vendor stack.

‍

Frequently asked questions

1. What is cryptographic discovery?
Cryptographic discovery is the process of locating every cryptographic asset in an environment (algorithms, keys, certificates, protocols, libraries, and the systems depending on them) including in cloud, on-premise, OT, and air-gapped zones.

2. Why is cryptographic discovery harder in critical infrastructure and defense?
Because the estate includes long-life hardware that cannot be patched, OT and ICS devices running legacy or proprietary protocols, and classified or sovereign networks where standard discovery tooling cannot collect or export findings.

3. What makes a system quantum-vulnerable?
Any system relying on public-key cryptography based on integer factorization or discrete logarithms: RSA, Diffie-Hellman, ECDSA, ECDH. Symmetric algorithms such as AES are weakened but not broken and remain viable at increased key strength.

4. How should remediation be prioritized?
By data lifetime first, then mission consequence, then current exposure. Systems protecting data that must remain secret for ten years or more, in high-consequence environments, and already exposed to collection, start immediately. For a step-by-step method, see our guide to building a NIST-aligned cryptographic inventory and migration roadmap.

5. What if a system cannot be migrated?
Compensate. Use segmentation, protocol mediation, and crypto-agile gateway layers to protect the asset without modifying it, and record it in an exception register with an owner and a review date. Never let an un-migratable system become undocumented accepted risk.

6. How do I evaluate a cryptographic discovery platform for these environments?
Test it live against all three zones, and confirm collection without outbound connectivity, controlled export, and sovereignty. Our cryptographic inventory buyer's framework includes a weighted scorecard for running that evaluation.

7. What are the governing deadlines?
NIST IR 8547 deprecates quantum-vulnerable algorithms by 2030 and disallows them by 2035, with high-risk systems transitioning earlier. National security systems follow CNSA 2.0, which sets earlier dates for many system categories. The UK National Cyber Security Centre (NCSC) asks for complete discovery and an initial plan by 2028 and full migration by 2035.

Sources: NIST IR 8547, Transition to Post-Quantum Cryptography Standards · NIST Post-Quantum Cryptography project · NCCoE Migration to Post-Quantum Cryptography · NCSC: Timelines for migration to post-quantum cryptography · National Security Agency: Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)

‍

‍

‍