In a recent conversation with Justin Richer, Senior Staff Engineer at MongoDB and longtime contributor to identity standards, and Richard Esplin, Head of Product at Dock Labs, we explored a contradiction in how enterprises implement Zero Trust: they work to eliminate perimeter-based trust, then recreate a perimeter around their identity infrastructure.
Organizations invest heavily in Zero Trust architecture: network segmentation, device health checks, dynamic policy enforcement, continuous monitoring. Then they place their IAM directory at the center of the environment, protect it with a firewall, and restrict which applications can access it.
They've built another perimeter. Just a smaller one.
This is not a new problem. In a 1994 Network World article, a Sun engineer reportedly described the weakness of firewall-based security using a metaphor that has stuck for decades: the hard shell and soft center of a Cadbury egg. The perimeter looks secure from the outside, but once an attacker gets through, everything inside may be implicitly trusted.
Zero Trust was designed to challenge that assumption. Yet some enterprise identity architectures preserve it in a different form.
Richard described a familiar pattern: an organization establishes a Zero Trust environment, places an IAM directory at its center, and decides that applications inside a defined boundary can access the directory while those outside cannot.
The problem isn't the directory itself. It's the assumption that being inside the boundary establishes trust.
And the complications don't stop there.
Because the directory holds critical identity information and supports many applications, organizations become protective of it. Adding new information can require changes that affect multiple dependent systems. Connecting new applications becomes a lengthy process.
When a team needs to deploy something quickly, it may bypass those processes and introduce another system outside the established boundary.
Over time, exceptions accumulate, the architecture becomes harder to manage, and the original security model becomes increasingly difficult to maintain.
One common response is to create another directory, synchronize it with the first, and use it for a different group of applications.
This provides flexibility, but introduces another problem: keeping everything synchronized.
As Richard illustrated, the second directory might be manageable. By the fourth, synchronization becomes painful. By the tenth, it can become practically impossible.
Justin pointed out that acquisitions make this even more complicated.
When one company acquires another, a common approach is to synchronize identity information between the two organizations' directories.
Each copy can end up being treated as an authoritative source, even though the information originated elsewhere.
Instead of creating isolated trust domains, the architecture distributes dependencies and trust assumptions across the organization. The result can be greater fragility, not greater resilience.
So what's the alternative?
Richard proposed changing how identity information moves between systems.
Rather than requiring every application to query a central directory, organizations can issue verifiable credentials containing information that other systems need to trust.
Users can carry those credentials in wallets and present them when accessing applications or moving between identity domains.
The directory can continue to perform identity proofing and issue credentials, but it no longer needs to act as the central repository queried for every interaction.
And importantly, this doesn't require every application to integrate with a wallet immediately. Organizations can start by using credentials to move information between existing identity domains, reducing their dependence on directory synchronization.
Justin added an important distinction about where trust sits in this model.
A verifiable credential doesn't eliminate the need for trust. Applications still need to establish whether the issuer is trustworthy, whether the credential is authentic, and whether its claims should be accepted.
Depending on the use case, the wallet itself may also need to meet certain trust requirements.
The difference is that an application can verify the information presented to it without depending on a direct connection to the directory that originally held the data.
It can apply its own policies and decide which issuers and claims it trusts.
That brings us back to one of Justin's most important questions from the conversation:
Zero Trust in what?
The goal isn't to eliminate every trusted component. It's to be explicit about where trust is placed, what is being verified, and which assumptions an architecture depends on.
Centralized IAM directories can be part of a Zero Trust architecture. But protecting them behind a firewall is not, by itself, enough to establish Zero Trust.
For organizations trying to make their identity infrastructure more secure and adaptable, the question is whether their architecture genuinely evaluates trust at each boundary, or simply moves the perimeter somewhere else.
