Assessing Cloud, Identity, Apps and Network — Quantum-Safe: Migration and Governance

Cryptography is not a single system you can inspect once and declare finished. It is spread through cloud services, identity platforms, application code, and network equipment, often in places that no one thinks about until a certificate expires or a connection fails. A quantum-safe assessment works because it is systematic: you walk each domain, ask the same hard questions, record what depends on vulnerable public-key cryptography, and turn the findings into decisions that owners can act on.

Start with the whole estate, not the loudest system

The first mistake in a quantum-readiness assessment is to chase the most visible cryptography and miss the quiet dependencies around it. A public website using Transport Layer Security, or TLS, is easy to notice. A federation signing key used by an identity provider, a hard-coded algorithm inside an older service, or an Internet Protocol Security, or IPsec, tunnel between sites may be less visible but more important.

Use four domains as your field map: cloud, identity and access management, applications, and network. They overlap, but separating them keeps the assessment disciplined. Cloud tells you what your providers operate and what you configure. Identity tells you who and what is trusted. Applications show where cryptography is embedded in code. Network shows where tunnels, gateways, and appliances protect traffic.

The goal is not to replace everything at once. The goal is to know what exists, what could be broken by a cryptographically relevant quantum computer, who controls the change, and how long that change will take.

📌

Use one lens. The same questions should follow you through every domain: what is vulnerable, who owns it, what is the roadmap, and how quickly can it change?

A disciplined assessment walks cloud, identity, applications, and network.

Cloud: separate the provider's work from your work

Cloud platforms use cryptography everywhere. TLS protects traffic to services and often traffic between services. Key Management Service, or KMS, products store and use cryptographic keys. Storage encryption protects disks, object stores, snapshots, backups, and databases. Some of this is entirely operated by the cloud provider; some of it is controlled by your configuration; some of it depends on customer-managed keys that your organization owns.

That split matters. If a managed service uses a public-key algorithm that must move to post-quantum cryptography, or PQC, you need the provider's roadmap. If your team controls certificate settings, customer-managed keys, private certificate authorities, or application-level encryption, you need your own migration plan. Cloud does not remove cryptographic responsibility; it divides it.

In cloud assessment, look especially for long-lived secrets and long-lived trust anchors. A data encryption key that is rotated frequently is a different risk from a signing key or root certificate that may be trusted for years. Also distinguish symmetric encryption from public-key cryptography. Quantum algorithms create the clearest break for widely used public-key systems such as RSA and elliptic curve cryptography, while symmetric encryption and hashing usually require different mitigations such as adequate key length.

Which managed services use public-key cryptography for TLS, certificates, key exchange, or signing?
Which keys are provider-managed, and which are customer-managed?
Where are long-lived keys, root certificates, or private certificate authorities used?
What has the provider published about PQC support, hybrid key exchange, and migration timing?
Which settings can your team change without waiting for a provider feature?

Cloud does not remove cryptographic responsibility; it divides it.

Identity: protect the system that says who is who

Identity and Access Management, or IAM, is the trust center of a modern environment. Single Sign-On, or SSO, systems issue signed tokens. Federation lets one identity provider trust another. Certificates authenticate users, services, devices, and workloads. If the signing keys behind these systems become forgeable, an attacker may be able to create believable tokens or credentials and impersonate users or services.

The assessment should identify how identity tokens are signed, which algorithms are used, where signing keys live, how certificates are issued, and how quickly trust can be rotated. This includes Security Assertion Markup Language, or SAML, tokens, OpenID Connect tokens, JSON Web Tokens, or JWTs, certificate-based authentication, and service-to-service identity systems.

Do not treat identity as just another application. A weak application may expose one workflow. A weak identity plane can undermine many systems at once because other services accept its assertions as truth.

⚠️

Identity blast radius. A forgeable identity signing key can turn into broad impersonation, not just a single broken login.

Applications: find the cryptography buried in code

Applications are usually the messiest domain because cryptography is often hidden in dependencies, helper functions, configuration files, and old code paths. One service may use a platform library for TLS, a separate library for token validation, another for data encryption, and a build pipeline tool for code signing. Different teams may not know they are using different cryptographic stacks.

Start with the Software Bill of Materials, or SBOM, you already use for vulnerability management, then extend the view into a Cryptographic Bill of Materials, or CBOM. The SBOM tells you which libraries and components an application depends on. The CBOM records cryptographic facts: algorithms, key sizes, certificates, protocols, crypto libraries, signing mechanisms, and ownership.

Dependency scanning helps, but it is not the finish line. Flag cryptographic libraries that are end-of-life, have known Common Vulnerabilities and Exposures, or CVEs, lack an obvious PQC roadmap, or force algorithm choices that cannot be changed easily. Then decide whether to upgrade the library, hide it behind an abstraction layer, refactor the calling code, or replace the component.

List the cryptographic libraries each application uses directly and indirectly.
Search for hard-coded algorithm names, key sizes, protocol versions, and certificate paths.
Check code signing for applications, containers, scripts, firmware, and deployment artifacts.
Record embedded keys and certificates, then determine whether they are still required.
Test whether algorithms can be changed through configuration or require code changes.

Extend the software bill of materials into a cryptographic one.

Network: start early because appliances move slowly

Network cryptography often lives in products that change on someone else's schedule. Virtual Private Network, or VPN, concentrators, TLS termination points, load balancers, secure web gateways, firewalls, and site-to-site IPsec connections may all rely on public-key key exchange or certificates. Some are software services; many are appliances or managed products with fixed release cycles.

This is why network findings often carry high difficulty-to-change. The technical fix may be straightforward in principle, but the practical path depends on firmware, vendor support, hardware capacity, procurement cycles, maintenance windows, and compatibility with remote peers. A tunnel is not migrated just because one side is ready.

Assess which tunnels and termination points use quantum-vulnerable key exchange, which certificates and trust stores they depend on, and whether hybrid key exchange is available. Hybrid approaches combine a classical method with a post-quantum method so that the connection is not relying on only one new mechanism during a transition period. Availability varies by product and version, so verify rather than assume.

⚠️

Slow does not mean later. Systems that take longest to change should enter the roadmap early, even if the final upgrade lands much later.

Ask the same questions in every domain

A good assessment is repetitive by design. The domains differ, but the core questions do not. What cryptography is in use? Does it depend on RSA, elliptic curve cryptography, or another public-key method that is not quantum-safe? Who owns the configuration, the code, the device, or the provider relationship? What would have to change? How long would that change take? What breaks if the change is delayed?

This consistency makes the results comparable. A cloud KMS issue, an IAM token-signing issue, an application library issue, and a VPN appliance issue can all be scored against exposure, data sensitivity, key lifetime, owner, roadmap, and difficulty-to-change. Without a common frame, the inventory becomes a pile of facts instead of a migration plan.

The assessment should also capture dependencies between domains. An application may be easy to update but depend on an identity provider that cannot yet issue different signatures. A network gateway may support a new mode, but a partner endpoint may not. A cloud service may be ready, but customer-managed certificates may still be using old algorithms.

The same dimensions make every domain's findings comparable.

Turn the assessment into real decisions

Leaders and practitioners need different views of the same evidence. Engineers need details precise enough to change a library, rotate a certificate, reconfigure a gateway, or test a new protocol mode. Leaders need to know which risks are material, which suppliers are on the critical path, where funding is required, and which decisions cannot wait.

The useful output is not a perfect inventory frozen in time. It is a living set of decisions. Some findings become quick configuration changes. Some become application refactoring work. Some become vendor roadmap questions with deadlines. Some become procurement requirements. Some become accepted temporary risks because the data is low sensitivity, the key lifetime is short, or the compensating controls are strong.

Make each decision explicit. Avoid vague statuses such as monitoring or pending. Say what is being watched, who owns it, what evidence is expected, and by what date the decision will be revisited.

Press a provider or vendor for a dated PQC roadmap when they control the implementation.
Change configuration when safer options already exist and compatibility is understood.
Refactor an application when algorithms are hard-coded or libraries are no longer maintainable.
Replace or phase out equipment when the vendor roadmap does not match your risk timeline.
Document temporary risk acceptance with an owner, reason, review date, and exit condition.

What to carry forward

Assessing cloud, identity, applications, and network gives you coverage across the places cryptography most often hides. Cloud is partly provider roadmap and partly your configuration. Identity is the center of trust and deserves special care. Applications are where buried dependencies and hard-coded choices appear. Network equipment is often slow to upgrade, so it needs early attention.

The practical discipline is simple but demanding: walk every domain, ask the same questions, record the answers in a CBOM, and attach each finding to an owner and a decision. If you skip a domain, you do not have a smaller assessment. You have an unknown door left open.

✅

Simple standard. A quantum-safe assessment is complete only when every major domain has been checked with the same method.

Key takeaways

Cryptography is distributed across cloud services, identity systems, application code, and network infrastructure.
Cloud assessment must separate what the provider controls from what your organization configures or owns.
Identity systems deserve priority because signed tokens, federation, and certificates define who and what is trusted.
Applications need SBOM and CBOM work because cryptography is often hidden in libraries, build systems, and hard-coded settings.
Network appliances and tunnels often have high difficulty-to-change, so vendor roadmap work should start early.
The best assessment uses the same questions in every domain and turns findings into owned decisions.

Glossary

Transport Layer Security: Transport Layer Security, or TLS, is the protocol commonly used to protect web and service traffic, including HTTPS connections.
Key Management Service: A Key Management Service, or KMS, is a service that stores, protects, and uses cryptographic keys on behalf of applications or users.
Identity and Access Management: Identity and Access Management, or IAM, is the set of systems that authenticate users and services and control what they can access.
Post-Quantum Cryptography: Post-Quantum Cryptography, or PQC, is cryptography designed to resist attacks by both classical computers and cryptographically relevant quantum computers.
Software Bill of Materials: A Software Bill of Materials, or SBOM, is an inventory of the software components and dependencies used by an application.
Cryptographic Bill of Materials: A Cryptographic Bill of Materials, or CBOM, is an inventory of cryptographic algorithms, keys, certificates, protocols, and libraries used by systems.
Virtual Private Network: A Virtual Private Network, or VPN, creates an encrypted tunnel across an untrusted network.
Internet Protocol Security: Internet Protocol Security, or IPsec, is a suite of protocols commonly used to secure network traffic, especially site-to-site tunnels.
TLS termination: TLS termination is the point, often a load balancer or gateway, where an encrypted TLS connection is decrypted before traffic is forwarded.