Cryptographic Exposure Maps: Preparing a Repository for Algorithm Migration

A repository search for algorithm names is a useful starting point for cryptographic discovery. It is not a migration plan. An organization must know which cryptographic function is being performed, which component selects the algorithm, which keys and protocols depend on it, what data it protects, who owns the system, and what interoperability constraints block replacement.

A cryptographic exposure map connects those facts while keeping repository evidence separate from deployment and runtime evidence.

Inventory use, not just presence

The string RSA can describe a key type, certificate, test fixture, compatibility branch, documentation example, library symbol, or live signature operation. Report the observed occurrence, then classify its role.

A useful inventory node includes:

NCCoE's migration work emphasizes discovering quantum-vulnerable public-key algorithms across hardware, software, and services and using inventories to support risk management and prioritization. NCCoE Migration to PQC project

Dependencies determine migration difficulty

Replacing a library call may be easy. Replacing a protocol or certificate chain across organizational boundaries may require coordinated standards, suppliers, hardware, key ceremonies, compatibility windows, and rollback.

Map relationships such as:

application → crypto API → provider/library → algorithm → key/certificate → protocol → peer → protected data

Then annotate the constraints:

• algorithm is hard-coded or configurable;
• protocol negotiates alternatives or requires one suite;
• key material is application-owned, KMS-managed, HSM-bound, or supplier-controlled;
• certificate and trust-anchor rollover require external coordination;
• signature verification must continue for historical artifacts;
• stored ciphertext must remain decryptable during and after transition;
• regulated or validated modules limit available choices.

NIST defines crypto agility as the capability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and operation. NIST CSWP 39upd1 The scope explains why a simple code replacement is rarely the whole migration.

Prioritize by function, exposure, and replacement path

Not every discovered primitive has the same urgency. A prioritization model can include:

1. cryptographic function and threat relevance;
2. sensitivity and required confidentiality lifetime of protected data;
3. external exposure and attacker collection opportunity;
4. algorithm and parameter status;
5. concentration or shared dependency across systems;
6. replacement availability and interoperability;
7. ownership, test coverage, and rollback readiness.

NIST's approved PQC standards cover different functions: FIPS 203 specifies a key-encapsulation mechanism, while FIPS 204 and 205 specify digital-signature mechanisms. NIST PQC standards announcement “Use PQC” is therefore not a sufficient remediation instruction. The replacement must match the cryptographic purpose and the protocol that consumes it.

Worked example: release signing

Suppose repository analysis finds an RSA signing library in a release job. The initial finding should expand into these questions:

• Which build artifact is signed and by which immutable identity?
• Is the private key in a managed signing service, CI secret, or hardware module?
• Which verification clients trust the corresponding public key or certificate?
• Must historical signatures remain verifiable?
• Can the artifact format carry multiple signatures during transition?
• Does a downstream policy require a named algorithm or certificate profile?
• Can a compromised workflow choose arbitrary bytes for signing?

The migration path may require format and verifier changes before the signer can change. It may also expose an authorization problem independent of algorithm strength: a workflow with unconstrained signing authority can authorize malicious artifacts under either classical or post-quantum cryptography.

Report coverage and uncertainty

Static repository analysis can observe source, configuration, manifests, infrastructure as code, workflow files, certificates checked into the repository, and some API use. It may miss:

• managed-service defaults and live key metadata;
• runtime negotiation and dynamically loaded providers;
• certificates and hardware outside source control;
• transitive library behavior;
• data-flow sensitivity and retention;
• supplier and partner dependencies;
• stale code that is present but unreachable.

The inventory should record those gaps explicitly and merge repository observations with authorized runtime evidence later. Missing discovery must remain “unknown,” never “no cryptography.”

Practical takeaway

Build the inventory around cryptographic function and dependency paths. Preserve the exact repository observation, add ownership and protected-data context, identify the component that controls replacement, and record evidence gaps. That turns discovery into a migration backlog without overstating static certainty.

Continue with Secure AWS Architecture: Decisions, Controls, Evidence, and Recovery for the broader key, policy, workload, and evidence context.

Limitations

This Article is not a cryptographic migration timetable and does not recommend algorithms for a particular system. Standards, protocols, validation requirements, supplier support, and threat assumptions change. Cryptographic design and production migration require specialist review and controlled interoperability testing.