Business criticality
Connect the technical dependency to the service or process it supports. A weakness in a low-impact test service and the same weakness in a critical payment or identity service do not carry the same consequence.
Risk perspective
Context turns inventory into risk intelligence.
A cryptographic inventory may reveal that hundreds of systems use a particular algorithm or protocol. That does not tell risk management which dependency should be addressed first, what business capability could be disrupted, or whether the organisation controls the migration path.
Prioritisation becomes possible when technical findings are connected to confidentiality and integrity needs, service criticality, exposure, ownership, data lifetime, vendor constraints and remediation complexity. NIST's PQC work explicitly links cryptographic visibility with risk management and migration planning.
A practical dependency model
Follow the chain from cryptography to business impact.
The exact data model will vary by organisation. For risk purposes, the goal is to preserve enough relationships to understand where a cryptographic change can create security or operational consequences.
01Business serviceWhat organisational capability depends on this?
02System / applicationWhere is the dependency implemented or consumed?
03Cryptographic useEncryption, signature, authentication, key establishment or another purpose?
04ImplementationAlgorithm, protocol, certificate, key, library, platform or managed service.
05Protected assetWhat data, transaction, identity or trust relationship is protected?
06Ownership & supplierWho can approve, implement or constrain the change?
Risk lens
A dependency is most useful when it answers three questions: what could be affected, why it matters, and who can change it.
What to connect
Relationships that change the risk decision.
Security purpose
Record whether cryptography provides confidentiality, integrity, authentication, signatures, key establishment or another control objective. The consequence of failure depends on the purpose.
Data sensitivity & lifetime
Understand what information is protected and how long confidentiality must remain effective. Long-lived sensitive data can change migration priority, particularly for future cryptanalytic threats.
Exposure & trust boundary
Distinguish internet-facing, partner-facing and internal use, and identify where cryptography crosses organisational or technical trust boundaries.
Technical ownership
Identify the team that operates or changes the implementation and the team accountable for the application or platform. Unknown ownership is itself a remediation risk.
Third-party control
Determine whether the organisation can change the cryptography directly or depends on a vendor, SaaS provider, cloud platform, library maintainer or managed service.
Change constraints
Capture interoperability requirements, legacy platforms, certification needs, release windows, protocol dependencies and other factors that can extend remediation timelines.
Lifecycle & roadmap
Know whether a system is strategic, being modernised or approaching retirement. Risk treatment should account for the realistic technology roadmap.
Evidence for risk management
What should risk management expect to see?
The objective is not to require every technical detail. Evidence should be sufficient to support prioritisation, accountability and an informed treatment decision.
TraceabilityA finding can be linked to a known system, service or technology component rather than existing as an isolated scan result.
OwnershipA responsible technical or service owner is identifiable, including where remediation depends on a third party.
Risk contextCriticality, security purpose, exposure and protected data are understood well enough to assess consequence.
Dependency contextMaterial upstream, downstream, protocol, platform and supplier constraints are known before a change is planned.
Treatment statusThe organisation can distinguish accepted, planned, in-progress, blocked and remediated dependencies, with exceptions governed appropriately.
Refresh mechanismThere is a way to update relationships as applications, suppliers, certificates, platforms and architectures change.
Prioritisation
Do not rank cryptographic risk by algorithm alone.
Same cryptographic weakness ≠ same organisational risk.
Priority emerges from the combination of cryptographic condition, security purpose, exposure, business impact, data lifetime, migration difficulty and the organisation's ability to control the dependency.
This also prevents a common governance failure: producing a technically correct list of weak or transition-sensitive cryptography without a defensible way to sequence remediation. Dependency mapping provides the context needed to move from finding to treatment plan.
Questions to ask
A risk advisor's conversation with technical teams.
Which business service or critical process depends on this cryptographic implementation?
What security property is it providing, and what would failure or deprecation expose?
What data is protected, and how long must that protection remain effective?
Is the implementation externally exposed or crossing an important trust boundary?
Who owns the technology, and who is accountable for accepting or treating the risk?
Can we change it ourselves, or are we dependent on a vendor or platform roadmap?
What other systems, clients, certificates, protocols or integrations could break if it changes?
What is the realistic remediation window, and what interim controls or exceptions are required?
Connection to quantum readiness
Quantum migration makes dependencies visible the hard way.
Post-quantum transition affects more than algorithm selection. NIST's migration project considers impacts across operating systems, application code, hardware, communications and key-management processes, while ENISA highlights the integration challenge for existing systems and protocols.
Mapping those relationships early allows an organisation to identify migration blockers and prioritise high-consequence dependencies before a deadline forces change.
Authoritative sources
Further reading
NIST NCCoEMigration to PQC FAQ — Cryptographic Visibility and Risk ManagementNIST NCCoEMapping Migration to PQC Capabilities to Risk Framework DocumentsNISTCybersecurity Framework (CSF) 2.0ENISAPost-Quantum Cryptography — Integration Study
This page synthesises public guidance through an information-security risk-management lens. It is educational material, not a normative control standard.