Assessing Cloud, Identity, Apps & Network

Key insight

Crypto is smeared across the whole estate; assess it domain by domain. Cloud (TLS, KMS, storage encryption — part provider roadmap, part your keys); Identity/IAM (signed tokens, certificates, federation — forgeable signing keys let attackers impersonate anyone); Applications (libraries, hard-coded algorithms, code signing — the messiest domain, where the CBOM earns its keep); Network (VPNs, TLS termination, IPsec — often slow-to-upgrade appliances, so high difficulty). Same questions, every domain, until the whole estate is covered.

In one sentence

Be systematic — walk cloud, identity, apps, and network with the same questions, because skipping one domain leaves a door open.

Cloud

Where crypto hides

TLS between services, key management services (KMS), storage/disk/database/object encryption. Much of this is the provider’s to upgrade; some is your own config and keys.

Which services use public-key crypto that quantum breaks?
What is each provider’s post-quantum timeline?
Where do you hold long-lived keys you control (customer-managed keys)?

Identity & IAM

Where crypto hides

Signed SSO tokens, service/user certificates, federation between identity providers. Forgeable signing keys let an attacker mint tokens and impersonate anyone — this is the beating heart of trust.

How are tokens signed, and with which algorithms?
How are certificates issued and rotated?
How fast could signing algorithms be changed?

Applications

Where crypto hides

The messiest domain: crypto libraries (sometimes several), hard-coded algorithm names, code signing, embedded keys and certificates. Dependency scanning and the CBOM earn their keep here.

Which crypto libraries does each app depend on?
Are algorithm names hard-coded, or swappable?
Is the app crypto-agile enough to change algorithms?

How to actually scan: the same dependency/SBOM scanners you already use for vulnerability management (for example Dependabot, Snyk, or OWASP Dependency-Check) list the crypto libraries each app pulls in. Flag a dependency when it is end-of-life, carries a known CVE, or has no published PQC roadmap. The output isn’t the end — feed each flagged library into the CBOM with an owner, then decide per app: upgrade the library, wrap it behind an abstraction layer, or schedule a replacement.

Network

Where crypto hides

VPN tunnels, TLS termination at load balancers/gateways, site-to-site IPsec. Often handled by appliances and vendor products that are slow to gain PQC support. Counter-intuitively, because they change slowly they need early attention, not late: the vendor’s release cycle is your critical path, so the conversation and procurement pressure have to start now even though the fix lands later.

Which tunnels/termination points use quantum-vulnerable key exchange?
What are the appliance vendors’ post-quantum roadmaps?
Can any support hybrid key exchange today?

Summary matrix

Domain	Crypto hides in	Key question	Typical difficulty
Cloud	TLS, KMS, storage encryption	Provider timeline? Your keys?	Low–medium
Identity/IAM	Tokens, certificates, federation	How are tokens signed?	Medium
Applications	Libraries, hard-coded algorithms, code signing	Agile enough to swap?	Medium–high
Network	VPN, TLS termination, IPsec	Appliance roadmap?	High

KMS: Key Management Service — a cloud service that stores and uses cryptographic keys.
Federation: Trust between identity providers, relying on signatures.
Code signing: Signing software so it can be trusted as authentic and unmodified.
TLS termination: The point (load balancer/gateway) where an encrypted connection is decrypted.
TLS (Transport Layer Security): The protocol securing service-to-service and internet traffic; behind HTTPS.
IAM (Identity and Access Management) / SSO (Single Sign-On): The systems that authenticate users and issue signed tokens — the heart of trust.
CBOM (Cryptographic Bill of Materials) / SBOM (Software Bill of Materials): The cryptographic and software inventories that dependency scanners feed.
OWASP (Open Worldwide Application Security Project) / CVE (Common Vulnerabilities and Exposures): A security community/tooling project, and the public catalogue of known vulnerabilities used to flag risky dependencies.
PQC (Post-Quantum Cryptography): The quantum-resistant algorithms whose roadmap you check for each provider, library and appliance.
VPN (Virtual Private Network) / IPsec (Internet Protocol Security): Network tunnelling technologies whose key exchange must move to PQC — often gated by appliance vendors.

What to carry forward

Assess four domains: cloud, identity, applications, network.
Cloud is partly the provider’s job; identity is the heart of trust; apps are the messiest; network appliances are the slowest to change.
Ask the same questions in each: what’s vulnerable, what’s the roadmap, how fast can it change?
Skipping a domain leaves a door open.

Next: The Maturity Model (0–5) → — score where you stand.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm learning to assess crypto across an IT estate. Quiz me one question at a
time, correcting me gently:

1. Name the four domains to assess and one place crypto hides in each.
2. Why is identity/IAM called the "heart of trust"?
3. Why are applications the messiest domain, and what tool helps most?
4. Why do network appliances often have high difficulty-to-change?
5. What's the danger of skipping one domain in the assessment?

References & further reading

CISA, NSA & NIST, Quantum-Readiness: Migration to PQC. cisa.gov/quantum
NIST NCCoE, Migration to Post-Quantum Cryptography project (discovery across domains). nccoe.nist.gov
NSA, Commercial National Security Algorithm Suite 2.0 (network & product timelines). CNSA 2.0 (PDF)
ENISA, Post-Quantum Cryptography: Current state and quantum mitigation. enisa.europa.eu