The breach that came through a help desk
The attacker does not need to break in. They log in.
In the autumn of a recent year, a group of English-speaking cybercriminals in their late teens and early twenties telephoned the outsourced IT help desk of one of the world’s largest hospitality operators. They already had employee names, roles and email addresses lifted from a professional networking site. They asked the help desk to reset a specific senior engineer’s password and enrol a new multi-factor authentication device to a phone they controlled. The help-desk agent, following the vendor’s documented process, verified identity using publicly-guessable data, made the changes, and hung up.
Within 48 hours the same attackers were inside the operator’s virtualisation infrastructure, disabling monitoring, deploying ransomware, and destroying VMware ESXi hosts at scale. Slot machines went dark. Digital room keys stopped working. Reservations systems failed. The operator later disclosed roughly USD 100 million in impact for a single quarter and reputational damage that lingered for years. Another major hospitality operator, hit by the same crew the same month, chose to pay a reported multi-million-dollar ransom.
No firewall was defeated. No zero-day was burned. No sophisticated exploit was developed. A telephone call was made, and the attackers became authorised users.
I return to that pattern constantly in conversations with banking, government, telco and utility clients because it is not an exceptional case. It is now the median case. Verizon’s most recent Data Breach Investigations Report attributes roughly two-thirds of all breaches to a human element, with stolen credentials the single most common initial-access vector across most industries. The attacker does not need to break through your firewall if they can convince your systems that they are you.
What actually changed
For most of the last three decades, we secured the enterprise by drawing a line around it. Firewall, DMZ, VPN. Inside the line, trusted. Outside, untrusted. Then came cloud, mobile, contractor workforces, SaaS, containerised microservices, machine-to-machine APIs, robotic process automation, and now agentic AI. The line stopped meaning anything.
Two shifts, both under-appreciated, changed the identity landscape more than any technical evolution in the underlying tooling.
The first shift is scale. The identity population inside a typical mid-sized enterprise today is dramatically larger than its human workforce. Employees plus contractors plus service accounts plus API keys plus cloud IAM roles plus machine identities plus workload identities plus privileged administrators plus third-party B2B federations plus, increasingly, AI agent identities. In client engagements I have seen human-to-non-human identity ratios of 1:20, 1:50, sometimes 1:200. The Cloud Security Alliance and multiple industry surveys now put the ratio of non-human identities to humans well above 40:1 in cloud-native environments. Most organisations cannot list them. Most cannot rotate them. Most have no lifecycle for them at all.
The second shift is that authentication and authorisation decisions are increasingly made by things that can be tricked. Help desks can be social-engineered. MFA push notifications can be spammed into approval fatigue. SMS one-time codes can be intercepted or SIM-swapped. Session tokens can be stolen from browsers. Adversary-in-the-middle phishing kits (of which several are freely available on the criminal ecosystem) can capture credentials and session cookies simultaneously, defeating any MFA method that is not cryptographically bound to the origin. Even single-sign-on identity providers, the crown jewel of the modern enterprise, have been compromised through their own support tunnels in recent years.
Once again, the industry has never been better equipped in principle. NIST Special Publication 800-207 defines Zero Trust Architecture rigorously. CISA has published a Zero Trust Maturity Model with five pillars and four maturity stages. FIDO2 and WebAuthn make phishing-resistant authentication mathematically achievable. Passkeys have shipped in every major consumer operating system. SPIFFE and SPIRE offer standards-based workload identity. OAuth 2.1 and OpenID Connect are mature. Just-in-time privileged access management, cloud infrastructure entitlement management, and identity threat detection and response are all commercially available product categories now. What is failing is not the tooling. What is failing is the deployment discipline and the identity-lifecycle governance in front of it.
Why traditional security failed
A leading cloud data warehouse recently disclosed that a criminal group had accessed customer tenants using valid credentials stolen through years of information-stealing malware from third-party contractor and employee endpoints. The warehouse itself was not breached. Its customers’ identities were, one at a time, using credentials for which the warehouse’s own controls could not distinguish “legitimate account holder” from “criminal group holding stolen credentials.” Multiple downstream Fortune 500 tenants (a global telecommunications carrier, a major concert-ticketing platform, a national health-insurance provider, several others) suffered public data disclosures totalling hundreds of millions of records. The common denominator across every impacted tenant was the absence of enforced multi-factor authentication on those specific accounts. The warehouse now enforces MFA by default; the horse and the barn were introduced after the fact.
A different pattern played out at a globally used identity provider. Attackers compromised the endpoints of third-party support contractors who had legitimate access to customer support portals, obtaining session tokens and, in one case, a full customer administrative console. From there they pivoted to a small number of downstream enterprise customers whose incident-response teams were watching closely enough to notice. The identity provider serving thousands of organisations was compromised through its own support supply chain.
A globally used password-management vendor lost encrypted vaults through a two-stage breach in which the initial compromise of a developer machine gave attackers access to source code and internal documents, which they used months later to compromise a DevOps engineer with keys to the customer-data backup storage. The vault-encryption architecture held for most customers with strong master passwords; the customers whose master passwords were guessable saw their credentials appear in criminal markets within weeks.
A major cloud-communications platform experienced a wave of SMS phishing against employees that ultimately compromised its internal administrative tooling, exposing customer messaging metadata and enabling secondary attacks on downstream customer accounts (including at least one large cryptocurrency operator).
The common pattern across every one of these incidents is the same as the hospitality case I opened with. Attackers did not defeat cryptography. They did not exploit unknown vulnerabilities. They walked in as authorised users through identities that the target’s own systems, help desks, or contractors had authenticated. Traditional perimeter security had nothing to defend against, because there was nothing at the perimeter to defend.
What is at stake
An identity compromise in a modern enterprise is not a data-loss event. It is a foothold event. A single compromised privileged identity can, in an unsegmented environment, provide direct access to core banking systems, national tax and social-services records, telecommunications provisioning infrastructure, utility control environments, national health-insurance databases, cloud platform tenants, and (a particularly recursive problem) the security tooling itself. In several publicly reported incidents, the attackers’ first action after obtaining privileged access was to disable or blind the very EDR, SIEM and IAM audit logs that were supposed to detect them.
The specific consequences boards should be modelling include: cascading compromise of interconnected systems (a single privileged token in a cloud tenant provides pivot into every SaaS federated to it); regulatory reporting obligations that trigger within hours (mandatory breach notification under Australia’s Notifiable Data Breach scheme, Europe’s GDPR Article 33, and equivalent frameworks in Singapore, India, Japan, the UK, the US and most other developed jurisdictions); executive personal liability under recent US SEC disclosure rules and similar directives now in force in Europe under NIS2; class-action litigation that has become almost automatic after significant identity breaches; and the emerging category of secondary breaches, where compromised identities from one incident are weaponised months later against unrelated victims through credential-stuffing at scale.
The scale problem is compounding. Machine identities and AI agent identities now outnumber human identities in most cloud-native enterprises. An AI agent equipped with tools (an emerging pattern I see in nearly every enterprise AI proposal) requires its own identity, its own scoped permissions, and its own audit trail. Most organisations are provisioning these identities with the same rigour they applied to service accounts a decade ago, which is to say almost none. When an autonomous agent has permission to send emails, invoke APIs, move money, or modify production systems, the compromise of its identity produces consequences that scale to whatever the agent was authorised to do.
Six moves I would ask an executive to schedule this quarter
One. Publish an identity inventory that includes non-human identities. Not the HR headcount. The complete list, cross-referenced to owners, expiry dates, entitlements and last-use. If your team says this cannot be done in a quarter, that is the finding. Cloud Infrastructure Entitlement Management tools automate most of it in weeks.
Two. Eliminate SMS and voice-call MFA for anything privileged, and eliminate app-push MFA for high-privilege human accounts. Move to FIDO2 hardware keys or platform passkeys. This is the highest-leverage single control on this list. It is what the pipeline case in the first article of this series was missing, and it is what would have blunted every incident I have described here.
Three. Rebuild your identity help-desk process for adversarial reality. Assume the caller has your organisation chart, your recent office locations, your employees’ family members, and any verification data that is publicly available. Verification must involve out-of-band challenges that a determined social engineer cannot fake, executed by staff who are explicitly rewarded for saying “no” to plausible-sounding requests.
Four. Implement just-in-time privileged access, not standing privilege. No human should hold a permanent domain admin, cloud root, or SaaS super-admin role. Requests for elevated access must be time-boxed (minutes to hours), justified against a ticket or change record, and logged in a system that the requesting user cannot themselves modify. This is the operational discipline behind Privileged Access Management and Cloud Infrastructure Entitlement Management categories; the products exist.
Five. Deploy Identity Threat Detection and Response. ITDR is now a distinct product category, monitoring identity-provider, directory-service, cloud-IAM and privileged-access telemetry for the specific attack patterns that signature-based EDR misses: impossible-travel logins, MFA-fatigue floods, session-token replay, unusual role assumption chains, dormant-account reactivation. Correlate ITDR with your SIEM and your OT-security stack.
Six. Treat machine and AI-agent identities as a distinct governance domain. Adopt SPIFFE-style workload identity, short-lived cryptographic credentials, per-workflow least-privilege scopes, mandatory rotation, and a lifecycle that tracks agent identities from creation to retirement. Post-quantum-ready credential formats are being standardised now under NIST FIPS 203 through 205 and should be part of any new architecture with a five-year lifespan.
The next three years
Three trends I would bet on.
Passwordless becomes non-negotiable for privileged access. Passkeys have crossed a threshold of consumer usability. Regulators will start treating passwords for privileged access the way they treat unencrypted email for medical records: technically permitted, practically indefensible in a breach.
AI agent identity becomes a first-class governance concern. Every serious AI framework being drafted (EU AI Act implementing acts, ISO/IEC 42001 guidance, NIST AI RMF profiles) is grappling with how to authenticate, authorise, audit and revoke AI agents that act on behalf of humans and organisations. Expect a distinct product category to emerge in the next 24 months.
Identity-provider concentration becomes a systemic risk. Two or three global identity providers now underwrite the authentication of a significant fraction of the world’s enterprise software users. A successful compromise of any of them would produce cross-industry cascading incidents on a scale we have not modelled. Regulators are starting to notice. Expect concentration risk to become a scheduled item in critical-infrastructure supervisor reviews.
The observation I want executives to sit with
Modern attackers do not defeat your controls. They log in through them. Everything downstream of that (data theft, ransomware, operational disruption, regulatory notification, class-action, headline) is a consequence of a single identity decision made by a system, a help desk, or a contractor. Most organisations still allocate cybersecurity budget as if the primary threat were external and technical. The primary threat is now internal, in the sense that it walks in with legitimate credentials, and human, in the sense that it exploits the humans who authenticate other humans on your behalf.
Next in this series: The Invisible Attack Surface – Your Supply Chain. I have written about how attackers walk in through identity. The next question is whose identity they use. In an enterprise where a substantial fraction of your privileged operators do not work for you (they work for your cloud provider, your managed service provider, your identity provider, your software vendors, your engineering-services partners), the identity is only as trustworthy as the third-party who authenticated it. That is the supply-chain problem, and it is the topic of the next article.
References and further reading
- Verizon 2024 Data Breach Investigations Report – https://www.verizon.com/business/resources/reports/dbir/
- CISA / FBI advisory on Scattered Spider (major hospitality-sector ransomware campaign) – https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
- Mandiant analysis of the cloud-data-warehouse tenant credential-theft campaign (UNC5537) – https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
- CISA Zero Trust Maturity Model v2.0 – https://www.cisa.gov/zero-trust-maturity-model
- NIST SP 800-207, Zero Trust Architecture – https://csrc.nist.gov/pubs/sp/800/207/final
- FIDO Alliance, Passkeys and phishing-resistant authentication – https://fidoalliance.org/passkeys/
- Cloud Security Alliance State of Non-Human Identity Security 2024 – https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report
- SPIFFE and SPIRE (workload identity standards) – https://spiffe.io/docs/latest/spiffe-about/overview/
- US SEC final rule on cybersecurity risk management, strategy, governance and incident disclosure – https://www.sec.gov/news/press-release/2023-139
- NIST FIPS 203 (ML-KEM), the post-quantum key-encapsulation standard – https://csrc.nist.gov/pubs/fips/203/final