Identity works well in stable systems.

It was designed for environments where users, devices, and networks are known in advance, where relationships can be defined ahead of time, and where the boundaries of the system are relatively fixed.

That model still underpins much of modern security architecture.

It also starts to break down the moment those assumptions no longer hold.

Across defence, critical infrastructure, and increasingly in commercial settings, operating conditions are no longer stable. Systems must support participants from different organisations, using a mix of managed and unmanaged devices, across networks that may be unreliable, degraded, or contested.

In these conditions, identity is still necessary, but it is no longer sufficient.

The problem is not that identity systems fail to identify users. In many cases, they work exactly as intended. Credentials are valid, authentication succeeds, and access is granted.

The issue is that identity answers a narrower question than the one systems actually need to ask.

Identity answers: who is this?

Modern systems increasingly need to answer: can this participant be trusted right now, in this context, for this interaction?

That distinction matters.

A user may have a valid identity but be operating from a compromised device. Credentials may be correct, but the surrounding context may have changed. A participant who should have access in one scenario may not be appropriate in another, even within the same operation.

Trust as a static property #

Traditional identity models struggle to account for this because they are built around persistence. Identities are provisioned, roles are assigned, and trust is established as a relatively static property. Once granted, that trust is often assumed to hold unless explicitly revoked.

In practice, trust is far more fluid.

Participants join and leave. Devices are swapped or shared. Connectivity shifts between networks with different levels of assurance. External dependencies may be unavailable or degraded. In some cases, there may be no opportunity to fully provision identities or enforce standard device controls before operations begin.

Under these conditions, identity becomes a weak proxy for trust.

This is not a new observation, but it is becoming more operationally significant as the environments in which systems are deployed continue to evolve.

Many approaches have attempted to address this through stronger authentication, multi-factor mechanisms, or tighter integration with centralised identity providers. These measures improve assurance at the point of access, but they do not fully resolve the underlying issue.

They still assume that trust can be established at a moment in time, and then carried forward.

From identity to verification #

A different model is required.

Rather than treating trust as something that is assigned based on identity, systems need to treat trust as something that is established and maintained continuously. This shifts the emphasis from identity to verification.

In practice, this means moving away from systems that rely on pre-provisioned identity and static trust relationships, towards models that can establish trust dynamically at the point of interaction. Trust is derived from the ability to create and maintain secure relationships in real time, rather than from credentials issued in advance.

This often involves the rapid establishment of shared secrets, frequent key rotation, and strong isolation between sessions. Each interaction becomes independently verifiable, limiting the extent to which trust can be assumed or carried forward. Compromise, when it occurs, is constrained rather than systemic.

Verification in this sense is not a single event. It is an ongoing process that considers not just who a participant is, but how they are interacting with the system, what device they are using, what network conditions apply, and how those factors evolve over time.

Design implications #

In practical terms, this leads to a number of design implications.

First, trust decisions need to be made at the level of sessions and interactions, rather than solely at the level of users or devices. This allows systems to adapt as conditions change, rather than relying on static assignments.

Second, systems need to reduce their reliance on external identity infrastructure, particularly in environments where connectivity cannot be guaranteed. While centralised identity providers have a role to play, they should not be a single point of dependency for establishing or maintaining trust.

Third, there is a greater emphasis on isolating interactions and limiting the scope of any single compromise. If trust is conditional and continuously evaluated, then the impact of failure in one part of the system can be contained more effectively.

These shifts do not render identity obsolete. Identity remains an important input into trust decisions. But it is no longer the foundation on which those decisions can safely be made.

Uncertain environments do not just stress communications systems. They expose the limits of identity-based security models.

Recognising that distinction is the first step. Designing systems that can operate under those conditions is the harder problem.