Beyond the Door #1: The Illusion of the Locked Door

One of the most dangerous phrases in security is:

“The control worked as designed.”

On the surface, it sounds reassuring. It suggests the system behaved predictably, that the engineering was sound, and that whatever happened next was outside the scope of the control itself. Throughout my career I’ve heard the phrase used in post-incident reviews, architecture discussions, risk assessments, and vulnerability triage meetings. Sometimes it is used to explain why something isn’t technically a bug. Sometimes it is used to justify a risk acceptance. Occasionally it becomes a convenient way of closing a discussion that nobody particularly wants to continue.

The thing is, it is often true. The control really did work as designed. The problem is that this observation, while factually correct, can completely miss the point.

Over the years I’ve repeatedly found myself investigating a security problem that initially seemed almost contradictory. The environment was protected by modern identity controls. Multifactor authentication was in place. Conditional Access policies were being evaluated. Device compliance was being assessed. The user had authenticated successfully and every relevant control had produced exactly the outcome it had been designed to produce.

Yet the resulting trust decision was wrong.

Not because a control had failed. Not because an attacker had discovered some spectacular bypass. Not because a developer had made an obvious mistake. The system had simply trusted information that it probably should not have trusted quite so readily. Every component in the chain had behaved according to specification, but the overall outcome was still problematic.

The more I dug into it, the more I realised I wasn’t really looking at a single vulnerability. I was looking at an assumption. In fact, I was looking at an assumption, or perhaps a nested set of assumptions like some cursed Matryoshka dolls, so deeply embedded within modern security thinking that most of us rarely stop to question it. Every layer I peeled back seemed to reveal another beneath it.

That distinction might sound subtle, but I think it sits at the heart of many modern security challenges.

For most of the history of enterprise computing, security has been built around boundaries. We built walls around data centres. We protected network perimeters. We created trusted zones and untrusted zones. We deployed firewalls, VPNs, proxies, and authentication systems whose primary purpose was to determine whether somebody should be allowed to cross from one side of a boundary to another. The technologies evolved over time, but the mental model remained remarkably consistent.

At its core, the model is remarkably simple. There is a boundary, somebody wants to cross it, and security’s job is to decide whether that should be allowed. Whether the boundary is a firewall, a VPN gateway, an identity provider, or a Conditional Access policy is almost irrelevant. The underlying question remains the same.

Even many of our most modern security controls remain descendants of this way of thinking. Conditional Access evaluates signals before issuing a token. Identity providers determine whether authentication requirements have been satisfied. Device compliance engines decide whether a machine meets the conditions required for trust. Risk engines calculate confidence scores that influence access decisions.

The controls themselves have become vastly more sophisticated than their predecessors, yet they remain focused on a familiar question: should this entity be allowed through the door?

It’s a reasonable question. In many circumstances it is an essential question. The problem is that access is only a moment in time. Trust is everything that follows.

Over the past decade, the environments we defend have become increasingly dynamic. Users move between networks and devices throughout the day. Applications communicate directly with other applications. Cloud services exchange tokens and assertions on behalf of users who may have authenticated hours earlier. Entire business processes execute across infrastructure that no single organisation owns or controls. The moment of authentication remains important, but it now represents only a tiny fraction of the overall trust relationship.

Despite this, many security architectures continue to behave as though the story ends at login. That remains true even in organisations that have enthusiastically embraced Zero Trust principles. The issue is not that Zero Trust is wrong. If anything, it recognised the problem years before most of us did. The challenge is that technology evolves far faster than mental models. We carry decades of assumptions about trust, access, and identity into every new architecture we build, often without noticing we’re doing it.

A user successfully completes multifactor authentication at nine o’clock in the morning and remains trusted throughout the day. A device reports itself as compliant and continues to inherit trust until the next evaluation cycle. An application receives delegated permissions and retains them long after the original business justification has faded from memory. The trust decision becomes a form of inheritance, passed forward through time even as the conditions that justified it gradually change. Trust becomes something that is inherited rather than continuously earned.

The real world, however, has a habit of refusing to stay still for our convenience.

Users travel. Devices drift from their original state. Permissions accumulate. Applications evolve. Sessions are replayed. Attackers gain access to systems that were entirely trustworthy when a session began but no longer deserve that same level of confidence hours, days, or weeks later. The context surrounding a trust decision can change dramatically while the trust itself remains untouched.

What makes many modern attacks particularly interesting is that they often exploit this mismatch directly.

Historically, security discussions tended to focus on how attackers might break through a control. We worried about password cracking, network exploitation, privilege escalation, and perimeter breaches. While those threats certainly haven’t disappeared, many contemporary attacks are surprisingly different. The attacker frequently has little interest in defeating the door itself. Why spend time breaking a lock when a valid key is already available?

Increasingly, adversaries inherit trust rather than bypass it. They steal tokens instead of passwords. They replay sessions instead of authenticating. They abuse legitimate applications instead of deploying obviously malicious tooling. They operate within trusted platforms using approved functionality and valid permissions. From the perspective of many traditional controls, very little appears unusual because the attacker is making use of the same trust relationships that legitimate users rely upon every day.

The door worked perfectly. The assumptions beyond it did not.

Cloud computing has amplified this challenge considerably. Trust is no longer established directly between a user and an application. Instead, it flows through increasingly complex chains of relationships. Identity systems trust devices. Applications trust identities. Services trust other services. APIs accept assertions from systems that never directly observed the original authentication event. Each individual relationship may be entirely reasonable in isolation, yet the overall result is an ecosystem where trust becomes inherited, delegated, exchanged, and extended far beyond the context in which it was originally established.

When everything works, this interconnected trust enables extraordinary levels of productivity. It allows organisations to scale, automate, and collaborate in ways that would have seemed almost magical a generation ago. When something goes wrong, however, it can become remarkably difficult to determine where trust should have ended and verification should have begun.

Now layer in modern supply chains, as I talked about in my recent post The Repository Is The New Package, and the trust boundaries have moved again.

And that’s before we even talk about AI agents, MCP servers, delegated agentic workflows, and the rapidly expanding bowl of trust spaghetti we’ve collectively decided to build.

At some point while thinking about these problems, I found myself reflecting on an unlikely source of inspiration: Monsters, Inc.

The Monsters, Inc. factory floor. A system built around managing doors.

At first glance, a Pixar film about monsters harvesting screams from children would seem an odd lens through which to examine modern cybersecurity. Yet the more I thought about it, the more useful the analogy became.

The entire economy of Monsters, Inc. revolves around doors. Every door is carefully catalogued, tracked, transported, secured, and managed. Entire departments exist to ensure that the correct monster reaches the correct door at the correct time. The door is treated as a critical control point because it represents a boundary between two worlds.

Modern security teams are similarly fascinated by doors.

We build authentication systems. We design Conditional Access policies. We implement compliance frameworks. We create risk engines and trust models. We invest enormous effort in determining who should be allowed through a boundary and under what circumstances.

What fascinated me about the analogy, however, was not the door itself but, rather, what happened after the door opened.

The entire system largely assumes that if the right monster accessed the right door, everything beyond that point will proceed as expected. The trust decision is concentrated at the boundary. Once that decision has been made, comparatively little attention is paid to the possibility that circumstances might change.

Security practitioners make similar assumptions every day, often without consciously realising it. A user authenticates successfully, their device reports itself as compliant, the application has been approved through the appropriate governance processes, and the session appears entirely legitimate. Each individual signal reinforces the others until a broader conclusion emerges: everything must still be fine. Most of the time that conclusion is correct. The problem is that the occasions when it isn’t are increasingly where the most interesting security failures occur.

Increasingly, the most interesting security problems live in that gap.

Not at the boundary itself, but beyond it.

This series is an exploration of that idea. Not how to build stronger doors, and not how to add yet another authentication prompt to an already frustrated workforce. Instead, I want to explore what happens after access is granted, why trust decays, how devices and identities often tell us comforting lies, and why visibility beyond the point of access may ultimately become one of the defining security challenges of the cloud era.

Because the most important question in modern security is no longer whether something got through the door.

It is whether we should still trust it once it is on the other side.

In the next article we’ll explore what happens when trust outlives the conditions that created it, and why access decisions should perhaps come with an expiry date.