When you buy a house, you check the roof, the windows, the electrical, the plumbing. What’s easy to miss because it’s underground and invisible is the foundation. If the foundation is compromised, the whole building comes down. Everything above it is irrelevant.
That’s where we are with cryptography in Zero Trust.
The CISA Zero Trust Maturity Model is one of the most important security frameworks in federal IT today. Its five pillars, Identity, Devices, Networks, Applications, and Data, provide a clear architecture for reducing implicit trust across enterprise environments. But there is an opportunity to strengthen how the model is structured. Cryptography sits as a detail inside the Network pillar rather than recognized as the foundational requirement it is. We think that is worth reconsidering.
“Without Encryption, All the Other Pillars Fall”
Every pillar in the CISA Zero Trust Maturity Model depends on cryptographic integrity to function. Every single one. I am not overstating this. After working in this field, I came to understand how fundamental encryption is to all of security, and how easy it is to lose sight of that. Let me walk through each pillar to build the case, using concrete examples of how cryptography underpins every one.
Identity uses digital signatures at its core. JSON Web Tokens, the standard mechanism for identity assertion in modern systems, are cryptographically signed. Forge that signature and every downstream access decision built on that identity claim is compromised. The entire premise of “verify explicitly” breaks. And signatures are only half the story. Those same tokens often carry scope claims that spell out exactly what the bearer is allowed to do, so they don’t just assert who you are, they shape what you are permitted to access. Authorization decisions ride on that cryptographically signed payload just as much as authentication does. Break the crypto and an attacker can mint or tamper with a token to grant themselves whatever scope they want, quietly escalating privileges while every downstream service still trusts the claim. Identity and authorization both collapse on the same cryptographic foundation.
Devices depend on cryptographic trust chains. Device certificates and hardware attestation are how a zero-trust architecture determines whether an endpoint is what it claims to be. Cryptographic integrity is what makes that chain hold. That chain is built on public key infrastructure. Every device certificate is issued by a certificate authority, and the whole model only works because a trusted CA cryptographically signs each certificate, binding an identity to a key pair the device can prove it controls. When an endpoint presents its certificate, the architecture validates that signature back up the chain to a root of trust, and it checks revocation to make sure the certificate hasn’t been pulled. Enrollment, renewal, and revocation all have to be managed at scale, which is exactly why PKI is operational plumbing, not a one-time setup. And if the algorithms underneath that CA are ever broken, an attacker can forge certificates the whole fleet will trust, and device identity across the enterprise falls with it.
Networks are the one place the current framework at least acknowledges encryption, through TLS and IPsec. But even here it’s buried as a feature. Network security runs on cryptography. The current framing obscures what actually needs to be managed and migrated. And there is a point people miss here: the conversation tends to fixate on encrypting the data in transit, but encryption on its own only buys you confidentiality. It keeps an eavesdropper from reading the traffic, and nothing more. It says nothing about who is on the other end of the connection. Without strong authentication you can be encrypting a perfectly private conversation with an attacker, which is why protocols like TLS authenticate the endpoints with certificates before any data flows. Trusting who you are talking to is just as foundational as protecting what you say, and both of those guarantees rest on the same cryptography.
Applications rely on HMAC hash validation and OAuth2 token integrity. Secure hashing is how applications verify that data hasn’t been tampered with in transit. That’s built into every authentication handshake. It is worth being precise about why this works. The HMAC value itself isn’t a secret, it travels alongside the data in the clear, so anyone can see it. What they can’t do is recompute or alter it, because an HMAC is keyed: producing a valid one requires a shared secret key, not just the message. That’s the difference between a plain hash, which anyone can regenerate after tampering with the data, and a keyed hash, which cannot be changed without the key. So even though the hash is public, an attacker who modifies the message can’t produce a matching HMAC, and the tampering is caught. Break the underlying cryptography, though, and that guarantee evaporates.
Data at rest is protected by symmetric encryption and key management systems. The encryption key is the security control. There is no data protection without a cryptographic strategy underneath it. And the hard part of data at rest was never the encryption itself, it’s the keys. Ciphertext sitting on a disk is only as safe as the key that unlocks it, so the real work is key management: generating keys, storing them in an HSM or key vault, rotating them on a schedule, and revoking them cleanly when something is compromised. This is also where the long lifetime of stored data bites. Information written to disk today may still be sensitive in ten or fifteen years, which means an adversary can harvest encrypted data now and simply wait, decrypting it once the underlying algorithm weakens. That “harvest now, decrypt later” exposure is why the cryptography protecting data at rest has to be chosen with its full retention horizon in mind, not just today’s threat model.
Now consider what happens when a single digital signature in this chain gets forged. Every pillar that trusts that signature is exposed. Best-in-class network controls, device policies, and access governance do not save you. The adversary is already inside, carrying a legitimate identity, on a trusted device, authorized by a poisoned token. One forged signature and all five pillars can fall together, because the foundation has given way. That is the real lesson of walking the pillars one by one: none of them stand on their own. Identity, devices, networks, applications, and data are all resting on the same cryptographic guarantees of confidentiality, integrity, and authenticity. Strip those guarantees away, and every pillar loses the thing that made it trustworthy in the first place. Which leads to the conclusion the whole model has been circling around: without the security guarantees that cryptography provides, you simply cannot do Zero Trust.
The Migration Scope Alone Makes the Case
Here’s what makes the current framing risky: cryptography is embedded everywhere, and migrating it takes a decade. And it only grows from here: every Zero Trust pillar you add multiplies the cryptography in play, so the footprint that needs to be managed and migrated keeps expanding rather than holding steady.
Not a sprint. Not a fiscal year initiative. A decade on average, and often longer, to inventory, prioritize, and systematically replace the cryptographic algorithms woven into enterprise infrastructure. That’s the scope of the post-quantum migration. NIST finalized its first post-quantum cryptographic standards in 2024. The clock is already running. And this is not a one-time event: cryptography changes over time. As new threats emerge, the algorithms adapt to stay ahead of them, and each of those changes has to be deployed across the enterprise. That recurring deployment challenge is what makes cryptography a foundation to manage continuously, not a box to check once. And it is worth being honest about where that cost comes from, because it is not just deployment labor. The algorithms themselves are the product of decades of painstaking work by the global cryptographic community. NIST’s post-quantum standards, for instance, came out of a multi-year, open competition in which cryptographers around the world proposed candidate algorithms and then spent years trying to break each other’s submissions. That adversarial scrutiny is the whole point: an algorithm only earns trust after it has survived sustained, public attempts to defeat it. Standing on the shoulders of that effort is what lets an enterprise treat a new algorithm as a real security guarantee rather than a hopeful assumption, and it is also why the work never truly finishes. Every time the research community strengthens or retires an algorithm, that hard-won progress has to be carried back into the enterprise, which is the recurring cost of keeping cryptography current.
No other element of Zero Trust carries that migration burden. You can retrain staff on identity hygiene in months. You can roll out new device management policies in a quarter. Cryptographic migration requires a dedicated, multi-year program with executive sponsorship, dedicated resourcing, and governance structures that don’t yet exist in most federal agencies, in part because the framework doesn’t yet call for it explicitly. And it is worth noticing what kind of work those other changes actually are. Retraining staff on identity hygiene or rolling out new device management policies are largely process-oriented efforts: they adjust how people request, grant, and review access, and they can be handled through the normal cadence of security operations, policy updates, and user training. In other words, most of the Zero Trust pillars evolve through changes to access processes and governance, which organizations already know how to run on quarterly or annual cycles. Cryptographic migration is different in kind. It is not a process tweak layered on top of existing access controls but a deep, technical replacement of the security primitives those controls quietly depend on, and that is why it demands its own dedicated program rather than fitting into the usual process-improvement rhythm.
When something requires its own strategy, its own roadmap, its own budget line, and its own governance program, it belongs in its own pillar.
What We’re Asking NIST and CISA to Do
In the near term, we’d encourage elevating cryptography to a named function within the Network pillar, giving it the visibility, specificity, and measurement criteria that other functions receive. This would move it out of the encryption footnotes.
In the next revision of the Zero Trust Maturity Model, we’d suggest recognizing Cryptography as a standalone sixth pillar.
The security field was built on cryptography. RSA, the world’s largest security conference, is named after the inventors of a cryptographic algorithm. The entire architecture of digital security rests on the assumption that certain mathematical problems are hard to solve. When that assumption changes, as it will with quantum computing, everything built on it gets exposed at once, across every pillar, in every agency, simultaneously.
Cryptography is the foundation this zero trust building sits on. Time to name it.
“Cryptographic agility” started as a clear technical argument stated publicly, carried forward until the field caught up. This is the same play. Taking a strong public stance and bringing people along is how frameworks evolve. It’s how change at the standards level actually happens. And the reason this matters so much comes back to a single point: every pillar of Zero Trust ultimately depends on the security guarantees that only cryptography provides. The confidentiality, integrity, and authenticity that let you verify identities, trust devices, secure networks, protect data, and authorize access are all cryptographic guarantees at their core. Take those away and there is nothing left to build trust on. Put plainly, without cryptography you cannot do Zero Trust. This is also why crypto agility belongs at the center of the conversation rather than the margins. NIST made the same case in its Cybersecurity White Paper 39, ”Considerations for Achieving Crypto Agility,” which lays out a strategy for building systems that can swap cryptographic algorithms in and out as standards change instead of hard-wiring today’s choices into place. That is precisely the capability every Zero Trust pillar needs, because the migration never ends and the algorithms will keep evolving. Treating cryptography as a first-class, agile foundation, exactly as CSWP 39 argues, is what turns “you cannot do Zero Trust without cryptography” from a warning into a workable engineering plan.
Let’s build on solid ground.
