Credential Stuffing at Scale — The Boring Attack That Still Breaks Everything

The Attack That Industry Defence Abandoned

The credential stuffing problem is not a problem of detection, automation, or threat intelligence—it is a fundamental failure of architecture that treats secrets as data rather than as a cryptographic boundary condition, and the entire industry consensus on "defence" has entrenched that failure so deeply that organisations now spend more money preventing attackers from proving the breach than preventing the breach itself.

How the Industry Sees It

The 2024 Snowflake customer cascade—which exposed millions of rows across Ticker, Advance Auto Parts, and dozens of other tenants—began not with a zero-day or a sophisticated nation-state technique, but with credential stuffing against Snowflake's web UI and programmatic API endpoints. Attackers acquired credential lists from prior third-party breaches (Linkedin, Okta, 3CX), enumerated accounts, validated access, and moved laterally through integration tokens stored in customer configurations. The incident was not unusual in its mechanism—it was unusual only in its scale and the speed at which downstream victims discovered compromise through automated detections.

Industry response has been entirely predictable. Vendors have amplified their Security Information and Event Management (SIEM) upsells—Splunk, Datadog, Crowdstrike now prominent in the conversation—with emphasis on behavioural analytics, anomalous login detection, and impossible travel rules mapped to MITRE ATT&CK technique T1078 (Valid Accounts). The National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) guidance on Account Management (PR.AC-2) has been codified into mandatory vendor onboarding: multi-factor authentication (MFA), conditional access policies, real-time login monitoring. The 2023 Change Healthcare ransomware incident—which exposed 100 million patient records following credential compromise across a legacy VPN—similarly triggered a vendor land-grab: MFA enforcement, session analytics, anomaly detection suites bolted onto identity platforms that were never designed to make stolen credentials useless.

The architectural outcome is now standardised: credentials are stored (in various degrees of encryption), validated against a central authentication service (Azure AD, Okta, on-premise LDAP), logged exhaustively, and monitored by downstream systems for "suspicious" patterns. The M&S Scattered Spider incident in 2025—where attackers gained initial access through social engineering and stolen contractor credentials, then used legitimate cloud authentication to pivot through AWS and retail systems—showed this model's brittleness: once a credential is valid, the entire security model assumes it is rightful. Detection-and-response (D&R) frameworks then rely on the attacker making themselves visible: unusual login time, impossible travel, bulk data access, privilege escalation. But credential stuffing often does not trigger these signals, particularly if attackers move slowly, respect existing behavioural patterns, or operate during business hours in the target's timezone.

The regulatory environment now codifies this assumption. The European Banking Authority's Regulatory Technical Standards (EBA RTS) on strong customer authentication (SCA) under the Payment Services Directive 2 (PSD2) mandate MFA for payment initiation but explicitly acknowledge that SCA does not prevent account takeover if the attacker possesses the credentials. The UK Financial Conduct Authority (FCA) Senior Management & Certification Regime (SM&CR) holds individuals accountable for information security governance, yet the FCA's regulatory perimeter—and the industry's collective implementation—still treats credential compromise as an incident to respond to, not a condition to prevent. Australia's Prudential Regulation Authority (APRA) CPS 234 (Information Security) similarly requires organisations to "implement and maintain" access controls, yet does not prescribe architectural separation between the act of authentication and the act of authorisation, creating the asymmetry that makes credential stuffing so efficient: one breach of authentication is sufficient to defeat authorisation.

The Structural Trap

What the industry narrative obscures is that credential stuffing is not an attack that can be solved by making credentials harder to steal or easier to detect when used. It is an attack that must succeed at scale because the attacker's cost-per-attempt is near-zero (a few milliseconds of API time), their success rate is non-zero (typically 0.1% to 2% across large corpuses), and their operational profile can be made to resemble legitimate traffic. A bank defending against T1078 does not need to stop attackers from using valid accounts—it needs to stop attackers from ever having valid accounts, or to make the account itself so cryptographically hostile that possession does not entail access.

The current model fails at this because it conflates three separable concerns: authentication (proof of knowledge/possession), authorisation (permission to perform an action), and audit (record of the action). All three are centralised; all three assume that authentication is sufficient proxy for authorisation. When an attacker credentials-stuffs their way into a Snowflake tenant, they do not need to defeat Snowflake's detection system—they need to be there long enough to load the data. If they move slowly, behave plausibly, and exit before anomaly detection thresholds are breached, they succeed. The Snowflake incident exposed exactly this: customers discovered compromise when Snowflake themselves detected unusual API activity (months after initial access) and notified customers whose logs showed exfiltration patterns. Detection happened after the breach, and remediation was reactive—password resets, token rotation, lateral movement hunting via forensic SIEM analysis.

The trap is structural because the industry's recommended solutions (MFA, SIEM analytics, conditional access) all operate within the same security model that credential stuffing exploits. Adding MFA means attackers must also acquire MFA factors (SIM-swap, push-notification fatigue, authenticator app compromise)—which is demonstrably happening at scale in 2024-2025. Adding detection means attackers must learn to hide better, which is also happening (slow exfiltration, legitimate-looking queries, API patterns that mirror scheduled jobs). The vendors profit from both—from the sale of MFA solutions and from the subsequent sale of detection-and-response platforms to spot attackers who bypassed MFA. The result is what NIST CSF calls "Detect" (DE) and "Respond" (RS) capabilities—which are necessary, but insufficient. They are offered as an alternative to architectural prevention, not as a complement.

Architecture as Boundary

The PULSE doctrine rejects this framing. Credential stuffing succeeds because the organisation's data plane—the systems holding sensitive data—trusts tokens issued by the control plane (the authentication service) without cryptographic verification that those tokens were acquired by a rightful principal. The gap between "I have a valid credential" and "I should be able to access this data" is closed only by procedural assumption, not by substrate guarantee.

A post-breach-resistant architecture separates these concerns explicitly. The data plane does not ask the control plane "is this person allowed?" Instead, it asks "do you cryptographically vouch for this transaction?" The difference is subtle but fundamental. A traditional architecture answers the first question by checking if the credential is in the "valid" set. A zero-knowledge architecture answers the second by verifying that a specific transaction (e.g. "read rows where customer_id = X") was authorised by a principal who both (a) authenticated to the control plane and (b) explicitly approved this specific data operation, not merely "logged in".

This requires architectural primitives that most organisations do not currently deploy. The data plane must be isolated from the control plane except via narrow, domain-specific channels. Authentication events (successful login) must be cryptographically bound to authorisation decisions (permission to access resource Y) at issuance time, not at access time. Session tokens must be short-lived and tied to specific operations, not to broad categories like "read all tables". Lateral movement—the ability to pivot from one system to another using the same authenticated session—must be architected away, not merely monitored.

Consider a concrete implementation. A financial services organisation processing payments typically separates: the identity provider (Okta, Azure AD), the API gateway (Kong, Apigee), the application tier (microservices), and the data tier (PostgreSQL, MongoDB, data lake). In the standard model, authentication succeeds at the identity provider, a session token is issued, and that token is trusted by all downstream systems. An attacker with credentials enters at the identity provider, receives a valid token, and can interact with any downstream system that trusts that token. In a zero-knowledge model, authentication succeeds at the identity provider, but the token issued is not a general-purpose session token. Instead, the identity provider issues a cryptographically signed assertion that binds the authenticated principal to a specific operation: "principal@example.com is authorised to invoke GetAccountBalance(account_id=12345) between 2025-02-15T10:00Z and 2025-02-15T10:05Z, signed by the identity provider's key, nonce=XXXXXXX". The API gateway validates this assertion's signature and nonce, then invokes the operation. The operation cannot be performed again with the same assertion. Lateral movement to a different endpoint (ListAllAccounts, ExportToCSV) requires a fresh assertion, which requires re-authentication or explicit authorisation by a privileged principal.

This is not theoretical. Financial cryptography has operated on this principle for two decades (HMAC-SHA256 bindings in SWIFT, public-key cryptography in PKI-based payment systems). The engineering is mature. What is missing is the will to implement it—because it requires treating authentication not as a centralised service that issues credentials, but as a boundary condition that must hold at every data operation.

Adaptive Posture in the Data Plane

Beyond cryptographic binding, a post-breach-resistant architecture must make the data plane itself adversarially adaptive. This means the substrate does not wait for detection-and-response to tell it something is wrong. Instead, it continuously drifts its posture in response to patterns that would be invisible to traditional anomaly detection.

If the data plane observes that a particular authenticated session is accessing rows it has never accessed before, that session's token can be automatically downgraded to a more restrictive assertion—without requiring human intervention, SOAR orchestration, or SIEM alerting. If a session attempts to read data in a novel sequence that mirrors known exfiltration patterns (e.g. SELECT FROM customers; SELECT FROM transactions; SELECT * FROM fraud_flags), the data plane can inject artificial latency, return partial results, or seamlessly migrate the data to a honeypot schema that appears identical but triggers immediate alerts if accessed. If login patterns suggest credential reuse across multiple principals (a sign of stuffing), the data plane can automatically invalidate all tokens from that principal and require fresh authentication via an out-of-band channel.

This requires domain-specific automation embedded in the data tier itself, not bolted on via SIEM or SOAR. A modern data warehouse (Snowflake, BigQuery, Redshift) can be augmented with these capabilities via stored procedures, function-level encryption, and stream processing on query logs—but only if the organisation has committed to architectural separation between the authentication boundary and the authorisation-and-access boundary. Legacy systems (Oracle, SQL Server, on-premise Postgres) require more engineering but remain tractable.

The Cost of Delay

The regulatory environment is beginning to acknowledge this. The EU's Digital Operational Resilience Act (DORA) and Network and Information Security Directive 2 (NIS2) mandate "appropriate technical and organisational measures" for access control, but stop short of mandating cryptographic binding or zero-knowledge proof. The UK's Central Bank's expectations around financial crime (SS7/23) similarly emphasise "controls", not specific architectures. This creates a gap: organisations can satisfy DORA, NIS2, and SS7/23 with MFA and SIEM—and many are doing so—while remaining deeply vulnerable to credential stuffing at scale.

The cost of this delay is now visible. The Snowflake incident alone exposed tens of millions of records across dozens of organisations. The Change Healthcare incident cost the organisation over $800 million in remediation and operational disruption. Organisations are spending billions on MFA deployment, SIEM licensing, and forensic incident response—all of which are necessary but not sufficient. They are necessary because attackers are getting credentials; they are insufficient because they do not make credentials useless.

The Path Forward

The choice before organisations is now explicit. Continue investing in detection-and-response, MFA, and behavioural analytics—knowing that they have reached their architectural ceiling and that credential stuffing will remain a permanent, high-probability threat. Or commit to architectural redesign: cryptographic binding of authentication to authorisation, data-plane separation, adaptive posture, and domain-specific automation. The second path is more expensive in engineering time and requires deeper technical decisions than the first. But it is the only path that moves credential stuffing from "incident we detect and respond to" to "attack we render structurally impossible".

For organisations serious about this transition, a detailed technical briefing under executed Mutual NDA—mapping your current identity, API, and data architecture against PULSE principles and specifying the phase-gate engineering roadmap—is available on request.