The Fortune 500 Illusion of Control

Identity rests on a software certificate authority that signs tokens. Access decisions are attribute-based: role, time, location, clearance. Enforcement lives at the network perimeter, attestation has a single source, and the response is hard deny — lock, block, quarantine. The SIEM is ground truth. Identity, Network and Security Operations are separate teams, with a 24/7 SOC.

On paper this is comprehensive. In my view, audits mostly measure whether controls are present, not the conditions under which they hold, so the blind spot appears on no artefact. Every control here assumes that authentication and access are the same moment, and that the network boundary separates trusted from untrusted. Neither assumption survives a session cookie lifted off an unmanaged home laptop, and nothing at sign-in asks whether the device is managed at all.

The Octagon states eight axioms an architecture must satisfy structurally, not nominally, and scores each one pass, partial or fail. Scored against the eight, Archetype B fails all of them: seven outright (Axioms 1, 2, 3, 4, 6, 7, 8) and one partially (Axiom 5), the same verdict as the overview's violation matrix. What it does have, a real PKI and a staffed 24/7 SOC, is why the breach is detected at all.

Seven it violates outright. No intrinsic trust (Axiom 1) holds in name only: the database trusts anything from the DevOps subnet. Policy is not verifiable (Axiom 2), because the decision point is a vendor black box no auditor can replay. Mediation is bypassable (Axiom 3), happening at the perimeter and nowhere after. Verification is not continuous (Axiom 4), happening at login and then not again. Byzantine fault tolerance is absent (Axiom 6), because the response can do more damage than the attack. Epistemic integrity is absent (Axiom 7), because the only evidence pipeline is one the attacker can reach. Bilateral symmetry is absent (Axiom 8), because the resource never proves its state to the requester. One it meets only partially. Bounded authority (Axiom 5): attribute-based grants are scoped, but nobody can calculate them, and the stolen session is able to create a new service account.

Timings are illustrative and compressed to keep the chain legible. For scale, CrowdStrike's 2026 Global Threat Report puts average breakout time at 29 minutes, and Mandiant's M-Trends 2026 puts global median dwell time at 14 days. It begins outside the perimeter. A senior DevOps engineer's personal laptop picks up commodity infostealer malware, which harvests browser-stored cookies, passwords and live OIDC tokens. Among the haul is a corporate session cookie, still inside the twelve-hour lifetime the enterprise configured. This is the shape of real incidents: in CircleCI's January 2023 breach, malware on an engineer's laptop stole a 2FA-backed SSO session that was then used from elsewhere, and in the 2024 Snowflake campaign, credentials harvested by infostealers led to bulk data theft from about 165 customers.

The VPN federates its login to the identity provider through browser SSO. At T+0 the attacker uses the stolen IdP session to complete that login. The signature checks out and the token has not expired. Because attestation has a single source, nothing else is asked: not whether this is the device that authenticated, not hardware attestation, not the behavioural baseline. The token is valid, therefore the user is present.

At T+3 minutes the attacker requests the production database. The policy engine checks role, hours, clearance and source network. All four match, because all four describe the engineer, and the attacker is wearing the engineer. No auditor can replay that decision, because the decision point does not export its reasoning.

At T+5 minutes the attacker is inside, and inside is flat. There is no application-layer mediation between the VPN subnet and the database subnet; mediation was a perimeter property and the perimeter is behind them. The database accepts the connection without its own identity check, because anything from that subnet has always been the DevOps team. Bulk exports begin, and the TLS-encrypted egress is not inspected.

The export generates very large logs, shipped to the SIEM by an agent on the database host the attacker now controls. At T+8 minutes the attacker pauses that agent. The SIEM registers a drop in log volume from one host, which happens routinely during maintenance windows, so it is not a priority-one event. The drop is filed as maintenance.

What eventually fires is not part of the zero-trust programme. At T+20 minutes the attacker attempts SSH into a legacy server carrying a hardcoded rule against SSH from an unrecognised ASN. The rule predates the vendor suite and is the one control that never assumed a valid token meant a legitimate user. The gap is twenty minutes to the tripwire and twenty-two to the moment the organisation knows it has an incident — long enough for full exfiltration.

The most consequential failure has the least visible symptom. The cookie stayed valid for twelve hours regardless of what changed around it: the device, the network path, the autonomous system, the behaviour. None of it mattered, because validity was a property of the token rather than of the situation.

This is what continuous verification means, and it is routinely misread as shorter token lifetimes. A shorter lifetime narrows the window without changing the model: a five-minute token still answers only whether it was signed, never whether the holder is still the entity that was authenticated. Continuous verification asks the second question at every access decision, using signals the token cannot carry — device binding, hardware attestation, behavioural baselines.

When the tripwire fires, hard deny executes as designed. It revokes the engineer's certificates, terminates the VPN pool address — locking out every user on it — locks the directory account, and quarantines the database server. Each action is defensible. Together they take production down.

At T+22 minutes the real engineer is paged at three in the morning and finds their own account locked. The siloed organisation processes one incident as three unrelated tickets: a lockout assumed to be a forgotten password, a blocked address closed as working as intended, and an alert investigated without knowing the three are one event. The responders are themselves locked out by the response, and the lockout does not revoke the service account the attacker created before the tripwire fired.

In the author's experience, a lockout cascade that takes down a critical function costs the programme, and sometimes the CISO, more than the breach did. That is an architectural failure, not a personnel one: a defensive response that harms the business more than the attacker did is what Axiom 6 rules out.

Three controls would have prevented the breach rather than trimmed it. The cheapest is device posture at sign-in: if the identity provider only issues corporate sessions to managed devices, the cookie never exists on the personal laptop. Device-bound sessions (DBSC, generally available in Chrome on Windows for Google accounts since May 2026; other sites must implement it themselves) break the chain at T+0: a copied cookie cannot be refreshed off the device whose key it is bound to. They do not stop malware using the session on the infected device itself. Identity-aware mediation at the workload breaks it at T+5: the database asks who is calling instead of where from, and network position stops being a credential.

Other controls only shorten the incident. Independent telemetry that alarms when a logging agent goes silent turns the T+8 blind spot into a detection, after exfiltration has started. Behavioural re-verification catches the shift to bulk extraction, after data has moved. A replayable policy engine makes the T+3 decision auditable, which matters afterwards and not during. Shared session signals (the OpenID Shared Signals Framework and CAEP, final since September 2025) let the identity provider revoke a live session when risk changes, which is the standard route to the continuous verification this archetype lacks.

There is an ordering constraint most programmes get backwards. Replacing hard deny with graduated friction — step-up verification, rate limiting, read-only degradation — must come before improving detection. Better detection with hard deny produces more outages, not more safety, and each outage ratchets the organisation away from zero trust through exceptions.

Archetype B does not describe incompetence. Procurement bought an integrated suite because integration reduces deployment risk, Identity ran a clean PKI, Network enforced at the boundary it owned. The failure sits between those decisions, where no team has ownership. One weakness in a shared management plane reaches every layer at once: the suite is a single trust anchor, not zero trust.

The practical test is short. Pick one production system and ask three questions. If a valid session token for it were copied to an unknown machine now, what would refuse it? If someone reached it from an approved internal subnet, what would ask who they are? If its telemetry went quiet, what independent signal would tell you? An architecture that cannot answer all three has this shape.