The question is not what is exposed. It is who can actually change it.
Two exposures with the same weight in the result can have remediation timelines years apart. One is resolved by a configuration change in an afternoon. The other depends on a manufacturer shipping firmware, on a maintenance window, and on a contract being renegotiated. Treating both in the same queue is what makes transition programs look stalled.
Configurable
These are the signals that depend on a decision the organization itself makes and applies: cryptographic negotiation policy, accepted versions, security headers, DNS records declaring who may issue certificates for the domain, certificate renewal and replacement. They share three properties: the owner is in-house, the change is reversible, and the effect is verifiable from outside on the next collection.
That is why they usually open the program. Not because they are the most important, since often they are not, but because they produce the first demonstrable before-and-after pair. A program that shows results early survives the next budget cycle better.
Structural
These depend on third parties or on architecture: cryptographic libraries embedded in old systems, equipment with cryptography in firmware, hardware modules, dependencies on providers that have not yet announced post-quantum support, contracted integrations that define the protocol. Here the decision owner is outside, or is inside but depends on a project with its own budget.
The common mistake is not underestimating these signals. It is finding them late. A supplier dependency with no post-quantum plan, identified early, becomes a clause in the next contract renewal. Identified mid-migration, it becomes a blocker with no contractual alternative.
Organizational
These are neither configuration nor equipment. They are cryptographic inventory, data shelf-life policy, the ability to swap algorithms without rewriting systems, program governance, supplier requirement criteria. They do not appear on the public surface: they enter the readout through the declared layer, and therefore exist only in complete mode.
They have the widest reach and the least visibility. An organization with real cryptographic agility treats every signal in the other two classes as maintenance. One without it treats each as a project. That is the difference between migrating once and migrating every time.
Do you publish the full signal-to-action mapping?
What this supports
- Separating what fits in the quarter from what needs its own project, before building the timeline.
- Taking cryptographic requirements into contract renewal, rather than into the middle of the migration.
- Treating cryptographic agility as an investment that lowers the cost of every migration that follows.
See what is outside the scope of this text
- A signal's class depends on the environment. What is configuration in one organization may be structural in another, depending on legacy and contract.
- The public readout reaches only the observable surface. Organizational signals depend on a declaration, and the declaration depends on whoever fills it in.