Privileged Access is the Single Point of Failure You Built On Purpose

The architecture that secures nothing

Every major breach of the past five years has pivoted on a single design decision: the belief that privileged access can be isolated, monitored, and revoked. It cannot. The moment you create a category called "privileged" you have announced to an adversary that a finite set of credentials, keys, or sessions will unlock everything else—and you have built a single point of failure at the precise location where detection is loudest and evasion is easiest.

The narrative: PAM as the industry's primary defence mechanism

The conventional reading is straightforward and deeply institutionalised. Organisations are told by auditors, frameworks, and vendors that privileged access management (PAM)—the operational control of administrator credentials, service accounts, secrets vaults, and session recording—is the primary bulwark against lateral movement and data exfiltration. The logic flows cleanly: if you control who can access what as admin, you control the blast radius. Products like CyberArk, BeyondTrust, HashiCorp Vault, and Microsoft's Privileged Identity Management (PIM) dominate enterprise security budgets. Compliance frameworks—NIST CSF, ISO 27001, SOC 2, PCI DSS 3.1, DORA, NIS2—explicitly mandate that organisations maintain PAM controls, audit privileged sessions, enforce multi-factor authentication on administrative access, and rotate credentials at regular intervals.

The 2024 Snowflake tenant cascade, in which attackers compromised multiple customer environments through shared service accounts and poorly-rotated API keys, appeared to validate this framework. Regulatory responses—including the SEC's four-day breach notification rule and NYSE proposals to mandate third-party supply-chain risk assessments—have only deepened investment in PAM tooling. Similarly, the 2023 MOVEit zero-day (CVE-2023-34362) demonstrated that when a single shared admin account was not properly isolated, adversaries using Progress's Transfer feature could move laterally across thousands of organisations. The Change Healthcare ransomware attack in early 2024, attributed to BlackCat and facilitated by compromised VPN credentials, further reinforced the narrative: strengthen PAM, enforce MFA, monitor anomalies.

Yet this narrative obscures a structural fact: PAM does not prevent privilege compromise. It makes privilege visible, auditable, and tradeable. When adversaries—particularly those operating under nation-state or financial motivation—encounter a well-lit PAM infrastructure, they do not retreat. They steal the administrative session, the vault token, the SSH key, the service account password. They then either use it legitimately (appearing indistinguishable from an insider), or they sell it on underground markets where the buyer uses it months later, after defensive attention has moved elsewhere. The Scattered Spider campaign against M&S in 2024, and earlier campaigns against MGM and Caesars in 2023, both pivoted on compromised credentials stolen from human operators or phished directly from email—credentials that existed within PAM systems, were audited regularly, and were nonetheless weaponised because audit trails alone do not prevent use.

The structural failure: privilege as a permission, not a property

The fundamental architectural error is this: privilege has been modelled as a permission to be granted, recorded, and revoked—rather than as a property that either does or does not exist in the data plane. The difference is absolute.

When privilege is a permission, it lives in a control plane: a database (Vault, PIM, Active Directory, LDAP, a PAM appliance) that can be queried, compromised, or manipulated before enforcement. An attacker who gains write access to that plane—through a stolen admin credential, a misconfigured API, a vulnerable management interface, or a supply-chain compromise of the vendor itself—can grant themselves privilege without detection. More insidiously, they can grant privilege that appears legitimate within the auditability framework. They can issue a privileged session token that logs correctly, that respects the organisation's stated policy, that rotates on schedule, and then abuse it in ways that appear to the organisation as normal administrative work.

The Optus breach of 2022 was instructive here. Attackers compromised an API endpoint that exposed unencrypted customer data—not through a vulnerability in a privileged access control, but through an overly permissive API gate that required no authentication at all. No PAM in the world prevents a developer from shipping an unauthenticated API. The Medibank breach, also 2022, leveraged compromised credentials and inadequate network segmentation; the data exfiltration proceeded across the network unobstructed, visible to network telemetry only after the fact.

When privilege exists as a property of the data plane itself—baked into the substrate architecture such that data can only be accessed through mechanisms that are cryptographically bound to an identity, that cannot be forwarded or delegated, and that automatically revoke on state change—then compromise of the control plane (the credential database, the vault, the identity provider) does not grant the attacker anything. They may be able to impersonate a user in the control plane; they cannot use that impersonation to extract data from the data plane, because the data plane does not know or care about the control plane's permission.

This is the doctrine of zero-knowledge substrate. The data plane must not trust the control plane to deliver privilege. It must enforce it independently.

The PULSE reading: why standard remediation deepens the failure

The industry's standard response to privilege compromise—implement stronger PAM, enforce passwordless authentication, mandate hardware security keys, deploy continuous risk scoring via User and Entity Behaviour Analytics (UEBA)—does not arrest the fundamental problem. It accelerates it.

Each new control-plane mechanism is another surface for compromise, another database for adversaries to prioritise, another audit trail that appears to offer visibility but in fact merely documents the attacker's work after they have already succeeded. CrowdStrike's EDR integration with identity systems, for instance, has the virtue of correlating suspicious process execution with user identity—but it does not prevent the suspicious process from executing in the first place. The Latitude Financial breach in 2023, which exposed millions of customer records, involved attacks against identity and access controls; subsequent analysis showed that even sophisticated detection tools missed lateral movement because the attacker used legitimate credentials to access unencrypted data stores.

UEBA systems like Okta's Behavior Detection Engine, Rapid7's InsightIDR, and similar products attempt to identify when a privileged account is behaving unusually—logging in from an impossible location, accessing resources outside its typical profile, moving data at an abnormal rate. But an adversary with months to study the environment can wait until the target user is actually performing their legitimate work, then use the credential during that window. Or they can establish a baseline of abnormal activity, gradually shifting the account's behaviour profile until suspicious activity becomes statistically normal.

The deeper issue: every control-plane-based remedy assumes that the attacker's goal is to avoid detection. Modern adversaries, particularly those with financial or geopolitical motivation, assume they will be detected—and they optimise instead for dwell time. They want to be inside the environment long enough to extract or destroy value before remediation can occur. Detection-and-response, the governing doctrine of the security operations centre (SOC), is a race condition they are willing to enter. PAM, UEBA, EDR, SIEM—these are all designed to shorten the window between compromise and discovery. They do not eliminate the window. They only make it narrower.

Architectural principles: data-plane isolation and continuous adversarial posture

An architecture that actually resists privilege compromise must separate the control plane from the data plane absolutely, and must place cryptographic enforcement in the data plane itself.

This requires several design principles, none of which are novel but all of which are rarely implemented:

Zero-knowledge substrate. Data must be accessible only through mechanisms that cryptographically bind access to an identity and a context. The storage system itself—whether a database, a file system, an API endpoint, or a message queue—must verify that the requester has the right to read or write before fulfilling the request. This verification must happen inside the data plane, not by querying a separate authentication service. If the authentication service is compromised, the data plane must remain inaccessible.

Data-plane vs. control-plane segregation. Administrative functions—user lifecycle management, role assignment, policy updates—must occur in a control plane that is architecturally isolated from systems that directly access data. An administrator who changes a role in the control plane does not gain the ability to read protected data; that ability must be independently enforced by the data plane. A compromised admin credential is therefore limited in scope to the control plane; the data plane remains intact.

Continuous adversarial posture adjustment. Rather than assuming a static set of permissions, the architecture must continuously vary the cryptographic mechanisms by which access is granted and verified. This is distinct from token rotation; it is a shift in the underlying protocol, the key derivation, the verification endpoint. An attacker who has compromised a credential may find it functional for 60 seconds, then non-functional, then valid again under a different cryptographic binding. This requires automation at the infrastructure level—not a manual process, not a scheduled job, but a continuous computational drift in the security posture itself.

Domain-specific primitives. Rather than applying generic RBAC (role-based access control) across all systems, access enforcement must be specific to the domain. A financial services organisation may require that any data access be bound to a specific transaction ID, a specific timestamp, and a specific regulatory mandate; code that attempts to access data outside that context should not merely be logged—it should be cryptographically rejected by the system itself. An intelligence organisation may require that access to certain datasets can only occur within specific geographic boundaries, enforced via geofencing primitives in the kernel. These are not policy overlays; they are hardwired into the data-plane architecture.

Implementation: toward substrate-level defence

This is not a call to eliminate PAM systems entirely. Control-plane hygiene remains important. But it must be decoupled from data-plane protection. An organisation should assume that the PAM system will be compromised; the architecture must remain secure under that assumption.

This requires re-examining where administrative functions actually occur. A database administrator who needs to tune a query does not need read access to customer data; they need access to query plans, execution statistics, and schema metadata. That access can be granted via a separate authentication plane that does not carry over into the data plane. A DevOps engineer who needs to deploy code does not need to read production secrets; they need to trigger a deployment process that the infrastructure itself performs, on their behalf, using secrets that the infrastructure holds and the engineer never touches.

Consider how this would have changed the Snowflake attacks: rather than storing API keys in a vault that could be compromised and used directly, Snowflake could have enforced that API access requires cryptographic proof of a specific deployment process. A stolen API key would authenticate to a control plane (allowing the attacker to see they had it), but would fail when attempting to query data, because the data plane would verify that the request came through the required deployment flow.

The architectural shift is non-trivial. It requires rethinking identity systems, secret management, data access patterns, and infrastructure automation. It demands domain expertise in cryptography, kernel-level security, and distributed systems. It is not a product to be purchased; it is an engineering discipline.

Closing the failure loop

The irony of modern privilege management is that it has become indistinguishable from privilege documentation. Organisations now have excellent records of who accessed what, when, and under what authority—records that are reviewed in breach post-mortems to understand how an attacker moved through the environment. The records do not prevent the movement. They merely explain it after the fact.

Data-plane-based privilege resistance, enforced via cryptographic substrate rather than policy overlay, is achievable. It is not common, because it requires architectural choices that conflict with operational convenience. Organisations prefer systems that are auditable, traceable, and forgettable—systems where privilege is a permission, not a property. The cost of that preference is paid in breach notifications, regulatory fines, and disclosed customer data.

Qualified operators at organisations holding or transferring material value should request a PULSE briefing under executed NDA to explore how zero-knowledge substrate architecture can be integrated into existing infrastructure without wholesale replacement.