More breaches in our database began with a credential someone else got hold of than with any software exploit, and the stolen credential usually belonged to a person whose login then unlocked keys, tokens and service accounts. This page is the NHI Mgmt Group hub for stolen credential breaches. It sets out what the State of NHI & AI Agent Breach Report 2026 found, places every fitting breach page in our database into five routes by which the credential was stolen, and explains for each how it unfolds, the warning signs, what failed and the controls that would have stopped it. It ends with what to do in the first 24 hours after a credential is reported stolen. It is for identity, security operations and platform teams; deeper pages are linked, not repeated.
Key takeaways
- Credentials open more doors than exploits. 99 breaches in the database began with a leaked, stolen or weak credential (44%), against 36 that came through an exploit, according to NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026).
- Stealing is a route of its own. 47 breaches came in through the stolen credentials route, a separate count from the 48 that started with a secret left lying in code, logs or tickets.
- A falling share is not a safer world. Only 25% of 2026 breaches were credential-led, down from 59% in 2023, but the report says supply chain and AI incidents now fill the list, and 26 of the 33 AI-related breaches in 2026 still abused a key, token or credential.
- The human login is the usual first step. Infostealer passwords, a VPN with no MFA, a help desk reset or a hijacked session gave the attacker a person's access, and that access reached machine credentials: vault keys, CI secrets, service accounts and OAuth grants.
- MFA alone did not hold. Push fatigue, relayed one-time codes, stolen sessions and application sign-ins all went round it. Phishing-resistant MFA, verified resets, short session and token lifetimes, and fast revocation did the work.
What the breach data shows
The report analyses 200+ breaches involving non-human identities and AI agents from November 2017 to October 2026. It counts a breach as credential-led when it began with a leaked, stolen or weak credential, and finds 99 of them: 44% of the database. By attack route, the stolen credentials route accounts for 47 breaches, leaked secrets for 48 and weak or default credentials for 7; a breach can have more than one route, so these do not add up to 99. Social engineering, the way many of these credentials were taken, is counted as its own route with 24. All figures below are as printed in the report; 2026 covers January to 7 October.
| Year | Breaches in the database | Credential-led share (as printed) | Supply chain or OAuth share | AI-related share |
|---|---|---|---|---|
| 2020 | 5 | 20% | 40% | 20% |
| 2021 | 17 | 53% | 35% | 0% |
| 2022 | 16 | 44% | 25% | 0% |
| 2023 | 27 | 59% | 15% | 15% |
| 2024 | 38 | 55% | 21% | 18% |
| 2025 | 63 | 43% | 29% | 30% |
| 2026 (to 7 October) | 53 | 25% | 42% | 62% |
The report is direct about the drop in 2026: it is not because credentials got safer. Supply chain attacks (38% of 2026) and AI incidents now fill the list, and 26 of the 33 AI-related breaches in 2026 still abused a key, token or credential. A stolen npm token behind a poisoned package is filed under supply chain, and an agent using a harvested cloud key under AI; in both, the credential was what the attacker needed.
For the stolen credentials route, the report's lifecycle mapping names Detection & Response and Secretless Credentials as the stages that stop it, and three controls: baseline each NHI and alert on deviations; revoke or rotate automatically; and MFA on every human login to data platforms, CI/CD and cloud. For social engineering it adds: verify help desk resets; alert on new OAuth apps, role changes and new credentials; and limit what one account can grant. The sections below turn those into specific steps for each route.
How this hub and its spoke pages fit together
The pages below go deeper on one slice each.
| Page | Use it for | Route |
|---|---|---|
| Infostealer Logs Monitoring and Response Guide | Monitoring stealer log markets and acting on a hit | 1 |
| Infostealer Logs and Session Token Abuse Guide | Cookies and tokens inside stealer logs | 1 and 4 |
| MFA Fatigue and Bypass Guide | Push fatigue, relay phishing and MFA method choice | 2 and 3 |
| How to detect use of a stolen OAuth refresh token | Detection queries and signals for token replay | 4 |
| Credential chaining | How one stolen login leads to the next credential | All |
| AI agent breaches | The 26 AI-related breaches that still abused a credential | All |
| Leaked secret breaches | Secrets left in code, logs and tickets, the sister route | Related |
Route 1: infostealer logs used against SaaS and data platforms
Malware on a personal or contractor device harvests saved passwords and cookies. The logs are sold or traded, and someone tries them against cloud data platforms, ticketing systems and partner portals that accept a password alone.
| Date | Breach | How the credential was stolen | Identity abused | Impact |
|---|---|---|---|---|
| Apr 2024 | Snowflake customers | Infostealer campaigns on non-Snowflake systems, earliest linked infection November 2020; at least 79.7% of accounts used had prior exposure (Mandiant) | Password-only Snowflake user accounts, including contractor credentials; no MFA, no rotation, no network allow list | About 165 organisations notified; about 100 million people affected; more than $2.5 million in ransom paid |
| Nov 2024 | Schneider Electric | Lumma infostealer on an employee's computer (Hudson Rock); attacker said "exposed credentials" | Jira credentials; the same machine held "cloud_migration" and "jira_migration" account credentials | More than 40GB claimed; about 400,000 user rows claimed; $125,000 demand |
| May 2025 | Scania | Credentials of a legitimate external user, assumed leaked by password stealer malware | One external user account on a partner-run insurance application | Insurance claim documents downloaded; 34,000 files claimed by a seller |
How it unfolds
The infection is on a machine the victim does not manage or watch, such as a contractor laptop or home PC, and the stealer takes every saved login. The credential then sits in a log for months or years; in Snowflake the earliest linked infection was 2020 and the logins were used in 2024. When it is finally tried, it works because the target accepts a password with no second factor, from any network, and the password was never rotated.
Warning signs
- Logins from new hosting or VPN ranges: to a data platform or ticketing system by an account that normally signs in from one office or one integration server.
- Bulk queries or exports shortly after first login: the Snowflake attackers ran reconnaissance and exports soon after access.
- Service-like account names on a human device: as with the migration accounts at Schneider Electric.
What failed
Password-only access to platforms that hold bulk data, credentials that never expired, no network limits, and no view of which external and contractor devices held working logins. Accounts created for a project, such as migration accounts, outlived the project and were stored alongside personal passwords.
Controls that stop it
- Turn off password-only sign-in on data platforms: require MFA for every human user, contractors included, and move service users to key pair, OAuth or workload federation. In Snowflake, set user TYPE to PERSON, SERVICE or LEGACY_SERVICE so policy can tell them apart; see the Snowflake Security Guide.
- Add network policy: restrict each service and integration account to the egress addresses of the systems that use it, and human access to corporate or ZTNA ranges.
- Monitor stealer logs and act within hours: subscribe to a feed covering your domains and SaaS URLs, and run the response in the section below on every hit. The workflow is in the Infostealer Logs Monitoring and Response Guide.
- Expire and rotate: set a maximum password age on any remaining password users, and alert on credentials older than your policy.
- Bring partner and contractor accounts into scope: require SSO from the partner's managed identity provider, or MFA you enforce, for every external user of a portal you own.
- Retire project accounts: give every migration or pilot account an owner and an end date, and disable it when the work closes.
Route 2: password-only human logins that unlocked machine credentials
A remote access portal, VPN, test tenant or admin system accepted a username and password. The attacker had the password from a leak, a spray or an unknown source, and the login led to the systems where service accounts, keys and OAuth permissions live.
| Date | Breach | How the credential was stolen | Identity abused | Impact |
|---|---|---|---|---|
| Apr to May 2021 | Colonial Pipeline | Password found in a batch of leaked dark-web passwords; original source unclear | A legacy VPN profile no longer in use but still active, no MFA | Pipeline shut down for six days; nearly 100 GB stolen; about 75 bitcoin paid |
| Sep to Nov 2021 | GoDaddy Managed WordPress | "A compromised password"; owner not disclosed | Provisioning system holding sFTP and database credentials, SSL private keys and admin passwords | 72 days of access; up to 1.2 million customers' emails and customer numbers exposed |
| Nov 2023 to Jan 2024 | Microsoft (Midnight Blizzard) | Password spray | A legacy non-production test tenant account without MFA, then a legacy test OAuth app and new malicious OAuth apps with full_access_as_app | Email exfiltrated from "a very small percentage" of employee accounts |
| Feb 2024 | Change Healthcare | Compromised credentials; source not publicly confirmed | An employee login on a Citrix remote access portal with no MFA | 192.7 million people affected; $22 million ransom paid |
| Oct 2025 | SonicWall SSL VPN accounts | Valid credentials of unknown origin, not brute force (Huntress) | More than 100 SSL VPN user accounts | Access across 16 customer environments; scanning and attempts on local Windows accounts |
How it unfolds
The entry point is usually a path the organisation forgot was there: a legacy VPN profile, a test tenant, an old remote access portal, a provisioning back end. MFA was rolled out to the main estate but not to these. Once in, the attacker finds the machine credentials the path can reach. At Microsoft the test account led to a legacy OAuth app with elevated access, and from there to application-level mail permissions; at GoDaddy the provisioning system held retrievable customer credentials and private keys.
Warning signs
- Successful logins to accounts with no recent use: dormant VPN profiles and test accounts that suddenly authenticate.
- Spray patterns: many accounts with one or two failures each from rotating addresses, followed by a success.
- New OAuth apps, consents or app role grants: created by an account that has never administered applications.
What failed
Incomplete MFA coverage, dormant accounts left enabled, test and legacy environments trusted by production, and systems that kept readable copies of credentials they had issued.
Controls that stop it
- Enumerate every login surface: list each VPN, remote access gateway, portal and tenant that accepts a password, and confirm MFA is enforced at the gateway, not only at the IdP behind it. Use Conditional Access to block legacy authentication; see the Conditional Access Guide.
- Disable dormant accounts automatically: set a no-login threshold (for example 30 to 90 days) for remote access and admin accounts, and require an owner to re-request.
- Give test tenants and legacy app registrations owners: review their permissions into production quarterly, and remove any cross-tenant trust they do not need. The Test tenants and legacy app registrations as a breach source page covers the review.
- Do not keep retrievable credentials: provisioning systems should hand a credential over once and keep only a hash, with private keys non-exportable.
- Detect sprays and new grants: alert on spray patterns and on any new OAuth app, consent or high-privilege application permission such as full_access_as_app.
Route 3: phished and socially engineered credentials, including help desk resets
The attacker persuaded a person to hand over a password and one-time code, approve a push, or reset an account. Often they did not steal a password at all: they talked the help desk or the self-service reset flow into giving them a new one.
| Date | Breach | How the credential was stolen | Identity abused | Impact |
|---|---|---|---|---|
| Mar 2022 | Mailchimp | Social engineering of employees | Employee accounts with an internal support tool that could read customer API keys | 319 accounts viewed; audience data exported from 102; API keys exposed |
| May 2022 | Cisco | Password synced from browser to a personal Google account, then vishing and MFA push fatigue | Employee VPN account, then domain controller credentials and machine accounts | Box folder and AD authentication data taken; no ransomware |
| Aug 2022 | Twilio | SMS phishing to a fake sign-in page relaying passwords and one-time codes | Employee SSO credentials | 209 customers and 93 Authy users; about 1,900 Signal users; 9,931 credentials across 130+ organisations in the wider campaign |
| Sep 2022 | Uber | Contractor's password likely bought on the dark web after malware, then MFA fatigue | Contractor account, then other employee accounts | G Suite, Slack, finance and HackerOne access; Uber rotated keys to many services |
| Oct 2022 | Dropbox | Phishing posing as CircleCI, relaying passwords and hardware key one-time passwords | Employee GitHub accounts; developer API keys in code | 130 repositories copied; exposed keys rotated |
| Sep 2023 | Caesars Entertainment | Social engineering of an outsourced IT support vendor | Not disclosed | Loyalty database copied; about $15 million reportedly paid |
| Sep 2023 | MGM Resorts | A help desk call impersonating an employee (attackers' account) | Okta and Azure tenant admin, per the attackers | About $100 million EBITDAR impact; about ten days of disruption |
| Apr 2025 | Marks & Spencer | Impersonation of a third-party user; reporting links it to the outsourced help desk | A contractor account and its reset process | About £300 million profit reduction before recoveries |
| Apr 2025 | Co-op | Impersonating staff to get an employee's password reset | Employee account, then the AD ntds.dit file | Data of 6.5 million members stolen |
| May 2026 | Storm-2949 (Azure) | Self-service password reset started by the attacker, with users talked into approving MFA prompts | Entra ID users with Azure roles, then Key Vault secrets, storage keys, SAS tokens and publishing credentials | Thousands of files downloaded; dozens of secrets read in four minutes |
How it unfolds
The attacker researches a target, then contacts the person or the help desk with a plausible story. A relay phishing page passes the password and code to the real site in real time; a push prompt is repeated until it is accepted; a reset agent is persuaded to enrol a new device. Storm-2949 automated the last step through self-service reset. Once the account is theirs, the attacker enrols their own MFA method and goes for what the account can reach: AD at Cisco and Co-op, the identity provider at MGM, Key Vault at Storm-2949, customer API keys at Mailchimp.
Warning signs
- Reset followed by new MFA enrolment: a password or MFA reset, then a new device or authenticator, then sign-in from a new location, within an hour.
- Bursts of push prompts: many denied pushes for one user, then an approval.
- Secret reads after a human sign-in: Key Vault, secrets manager or support tool access by a user who rarely reads secrets.
What failed
Phishable MFA methods, reset processes that trusted information an attacker could find, outsourced help desks outside the company's control, and human accounts that could read machine credentials in bulk. See the MFA Fatigue and Bypass Guide for the method detail.
Controls that stop it
- Phishing-resistant MFA for privileged and engineering users first: FIDO2 security keys or platform passkeys bound to the origin, which a relay page cannot pass on. Twilio moved all employees to FIDO2 keys after its breach; see the Phishing-Resistant MFA Guide.
- Verify every reset out of band: require a manager or known-device callback, or video identity verification, before resetting a password or MFA method; apply the same rule to the outsourced help desk in contract. The steps are in the Account Recovery and Help Desk Security Guide.
- Tighten self-service reset: require two methods, at least one phishing-resistant, and block reset for privileged roles.
- Hold new MFA enrolments: notify the user on a known channel and delay sensitive access for a period after a new method is registered.
- Separate human accounts from secret stores: people should not hold standing read on vaults, customer API keys or deployment credentials; grant it just in time with approval.
- Rehearse the playbook: the Help Desk Social Engineering Incident Playbook covers what to do when a reset turns out to be fraudulent.
Route 4: stolen session and OAuth tokens
Here the attacker skipped the login altogether. They took a session cookie, a cloud session or an OAuth token that had already passed authentication, and replayed it.
| Date | Breach | How the credential was stolen | Identity abused | Impact |
|---|---|---|---|---|
| Dec 2022 | CircleCI | Malware on an engineer's laptop stole a valid 2FA-backed SSO session | The SSO session, production access tokens, then customer secrets and platform encryption keys | Customer secrets exfiltrated; all customers told to rotate |
| Sep to Oct 2023 | Okta support system | Support service account credential saved in a personal Google profile in Chrome | The service account, then customer session tokens inside uploaded HAR files | Files for 134 customers accessed; five customers' sessions hijacked |
| Feb 2025 | Bybit (Safe{Wallet}) | Developer laptop compromised through a malicious Docker project | Active AWS session tokens, used to bypass MFA | About $1.5 billion stolen |
| Mar to Aug 2025 | Salesloft Drift | From Salesloft's GitHub account into Drift's AWS environment | OAuth access and refresh tokens for Drift's Salesforce and Google Workspace integrations | Over 700 potentially impacted organisations (Google) |
| Oct to Nov 2025 | Gainsight | Stolen OAuth tokens; how they were first obtained not established | 285 Salesforce tokens created between October 2017 and August 2023 | More than 200 potentially affected Salesforce instances (Google) |
How it unfolds
Tokens are bearer credentials: whoever presents one is treated as the user or app it was issued to, and MFA has already been satisfied. They are taken from endpoints (CircleCI, Bybit), from files where people paste them (Okta HAR files), or from the systems that store them for integrations (Drift, Gainsight). Long lifetimes do the rest: Gainsight's own root cause was that "OAuth tokens were allowed to live too long", with some tokens years old. The attacker arrives as an already-authorised session or application, so SSO and MFA never see them.
Warning signs
- One session, two places: a session or refresh token used from a new ASN, country or device fingerprint while the original holder is still active.
- Integration traffic from new addresses: a connected app's API calls coming from outside the vendor's published ranges, or bulk export queries it has never run.
What failed
Long token lifetimes, sessions not bound to a device, tokens stored where they could be read in bulk, and no inventory of which integrations held which grants. The detection detail is in How to detect use of a stolen OAuth refresh token, and session abuse from stealer logs in the Infostealer Logs and Session Token Abuse Guide.
Controls that stop it
- Shorten lifetimes: cap session length for admin and production access (hours, not days), and set refresh token expiry and inactivity timeouts on every connected app your IdP or SaaS allows.
- Bind sessions to devices: use token protection or device-bound session features where your IdP offers them, and require a compliant managed device for production consoles.
- Step up before minting tokens: require fresh phishing-resistant authentication to generate production tokens or keys, one of the lessons our CircleCI page draws.
- Restrict integration tokens by network: where the SaaS supports IP restrictions on connected apps, pin them to the vendor's ranges.
- Sanitise support artefacts: strip cookies and tokens from HAR files before upload, and treat support systems that store them as secret stores.
- Inventory and revoke grants: list every OAuth grant by app, scope, age and last use; revoke unused ones. See the OAuth and SaaS integration breaches page and the SaaS integration token breach response page.
Route 5: credentials taken from developer and vendor systems
The credential was stolen from a place that held many of them: an engineer's vault or home computer, a vendor's backend, or a third party trusted with tokens. The victim never had a chance to see the theft.
| Date | Breach | How the credential was stolen | Identity abused | Impact |
|---|---|---|---|---|
| Aug to Oct 2022 | LastPass | Keylogger on a senior DevOps engineer's home computer via vulnerable media software | AWS access keys and backup decryption keys in the engineer's corporate vault; a trusted device cookie | Customer vault backups copied; up to 1.6 million UK users; £1.2 million ICO fine |
| Dec 2022 | Slack | Employee tokens stolen through a compromised third-party vendor | A limited number of employee tokens with GitHub access | Private repositories downloaded; no customer data |
| Nov 2023 | Sumo Logic | A compromised credential; method not disclosed | An AWS account credential | No customer data impact found; customers asked to rotate API keys |
| Nov 2023 | Cloudflare | Credentials stolen in the Okta support breach, not rotated because they were thought unused | A Moveworks service token, Smartsheet and Bitbucket service accounts | 120 repositories viewed, 76 treated as exfiltrated; more than 5,000 credentials rotated |
| Sep 2024 | Storm-0501 | Plain text Entra Connect Sync credentials extracted from sync servers, after stolen or weak credentials for entry | Sync accounts, Domain Admin, a cloud Global Administrator without MFA | Domains and Entra tenants compromised; ransomware in some cases |
| Dec 2024 | BeyondTrust | API key for Remote Support SaaS; method undisclosed | The API key, used to reset local application account passwords | US Treasury workstations accessed |
| Jun 2026 | Klue | A previously compromised GitHub PAT, issued to a third party in 2022 for a pilot | The PAT, then customers' Salesforce OAuth tokens | About 13.9 million records in the largest case analysed (Obsidian) |
| Oct 2026 | ConnectWise Cloud Backup | Stolen credential for the multi-tenant app; exposure method undisclosed | The Cloud Backup service principal, then Cloud Management service principals that gave themselves roles | 162 tenants with confirmed unauthorised sign-ins (Huntress); Global Administrator in one |
| Oct 2026 | UpdraftCentral | Vendor site accessed and customer database most likely taken | Non-expiring UpdraftCentral connection keys used to sign commands | 99 distinct backdoor plugins observed; about 400,000 sites potentially exposed |
How it unfolds
Engineers and vendors concentrate credentials. A DevOps engineer's vault holds production cloud keys; a SaaS vendor holds every customer's OAuth tokens; a remote management service holds keys to every connected site. When one of these is breached, every credential it holds is stolen at once, and none of the owners see it. Cloudflare shows the second-order effect: Okta breach credentials used weeks later because four were left unrotated.
Warning signs
- A supplier announces a breach: treat it as a theft of every credential they held for you until proven otherwise.
- Vendor identities doing new things: a vendor app or service principal assigning roles, adding secrets to other apps or signing in from a new address, as at ConnectWise.
- Cloud API calls from a key normally used only by a backup or batch job: from an interactive location or outside its schedule.
- Old tokens issued to third parties still active: such as Klue's 2022 pilot PAT.
What failed
Long-lived machine keys stored in human vaults and on home devices, vendors holding non-expiring keys, incomplete rotation after a supplier breach, and Tier 0 sync servers protected like ordinary servers. The Developer endpoints as NHI stores and Incomplete rotation breaches pages go deeper.
Controls that stop it
- Move workload keys out of human vaults: backup and data jobs should use workload identity or short-lived role credentials, with decryption keys held separately from data access.
- Rotate everything a breached supplier held: keep a register of which credentials each vendor holds so rotation takes hours, and verify "unused" before skipping any.
- Treat remote access and PAM vendors as Tier 0: require expiry on their keys, IP restrictions and notification commitments; see Remote access and PAM vendors as tier-zero suppliers.
- Protect sync servers like domain controllers: follow the Microsoft Entra Connect and Cloud Sync Hardening Guide, and keep cloud admin accounts cloud-only with phishing-resistant MFA.
- Expire third-party tokens: every PAT or key issued for a pilot gets an end date and an owner; scan for active tokens past their purpose.
- Alert on vendor app privilege changes: role assignment or credential addition by any multi-tenant app should page someone.
When a credential is reported stolen: the first 24 hours
Whether the report comes from a stealer log feed, a supplier or a user, these steps apply across all five routes.
| Time | Action | Why |
|---|---|---|
| Hour 0 to 1 | Confirm the credential and its owner; identify whether it is a password, session, token or key, and what it can reach | Scope drives everything after; a session needs revoking, not just a password reset |
| Hour 0 to 1 | Revoke sessions and refresh tokens, reset the password or rotate the key, and remove any MFA methods registered since the suspected theft | A password reset alone leaves stolen sessions and attacker-enrolled devices working |
| Hour 1 to 4 | Pull sign-in and audit logs for the identity back to the earliest possible exposure date, not just the report date | Snowflake credentials were stolen years before use |
| Hour 1 to 4 | List every secret, vault entry, OAuth grant and service account the identity could read or create, and check for new ones it created | Attackers chain to the next credential; see Credential chaining |
| Hour 4 to 12 | Rotate the machine credentials found, highest privilege first, and confirm the old values are rejected | Cloudflare's breach came from four credentials thought unused |
| Hour 4 to 12 | For an infected device: isolate it and treat every credential saved on it, personal profiles included, as stolen | Stealers take everything; Schneider Electric's machine also held migration accounts |
| Hour 12 to 24 | Hunt for persistence: new OAuth apps, app secrets, role assignments, mailbox rules, MFA enrolments and federation changes | Midnight Blizzard, Storm-0501 and ConnectWise all added identities or credentials |
For a supplier breach, the same steps run against the register of credentials that supplier holds.
Detection and measurement
| Measure | Target |
|---|---|
| Share of human logins to data platforms, CI/CD and cloud with enforced MFA, contractors included | 100% |
| Share of privileged and engineering users on phishing-resistant MFA | Rising each quarter to 100% |
| Time from stealer log hit to session revocation and reset | Under 4 hours |
| OAuth grants with no owner or no use in 90 days | Zero |
| Help desk resets for privileged users with recorded out-of-band verification | 100% |
Framework mapping
| Framework | Reference | Route |
|---|---|---|
| MITRE ATT&CK v20 | T1078 Valid Accounts; T1078.004 Cloud Accounts; T1133 External Remote Services; T1110.003 Password Spraying | 1 and 2 |
| MITRE ATT&CK v20 | T1555.003 Credentials from Web Browsers | 1 and 3 |
| MITRE ATT&CK v20 | T1566.002 Spearphishing Link; T1566.004 Spearphishing Voice; T1621 Multi-Factor Authentication Request Generation; T1098.005 Device Registration | 3 |
| MITRE ATT&CK v20 | T1539 Steal Web Session Cookie; T1550.004 Web Session Cookie; T1528 Steal Application Access Token; T1550.001 Application Access Token | 4 |
| MITRE ATT&CK v20 | T1199 Trusted Relationship; T1552.001 Credentials In Files; T1098.001 Additional Cloud Credentials | 5 |
| OWASP Non-Human Identities Top 10 | Long-lived secrets, improper offboarding, overprivileged NHIs | 2, 4 and 5 |
| NIST SP 800-53 Rev 5 | AC-2 Account Management; IA-2 Identification and Authentication; IA-5 Authenticator Management; SI-4 System Monitoring | All |
| NIST SP 800-63B | Authenticator assurance levels and phishing resistance | 2 and 3 |
Common failure patterns
- MFA everywhere except the forgotten door: a legacy VPN at Colonial, a Citrix portal at Change Healthcare, a test tenant at Microsoft.
- Resetting the password but not the session: stolen sessions and attacker-enrolled devices survive a password change.
- Corporate logins in personal browser profiles: Cisco and Okta both began there.
- "Unused" without proof: Cloudflare's four unrotated credentials.
Practitioner checklist
- Enforce MFA on every human login to data platforms, CI/CD, cloud consoles and remote access, contractors included.
- Move privileged and engineering users to phishing-resistant MFA.
- Require out-of-band verification for every password and MFA reset, including at outsourced help desks.
- Subscribe to stealer log monitoring for your domains and SaaS URLs and respond within hours.
- Disable dormant remote access, admin, test and project accounts automatically.
- Cap session and refresh token lifetimes and bind admin sessions to managed devices.
- Inventory OAuth grants and third-party tokens with owner, scope, age and last use; revoke the rest.
- Move workload keys out of human vaults to short-lived workload credentials.
- Keep a register of credentials each vendor holds and rehearse rotating them.
- Rehearse the first 24 hours response, including session revocation and persistence hunting.
Standards and references
- NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
- MITRE ATT&CK: T1078 Valid Accounts
- MITRE ATT&CK: T1539 Steal Web Session Cookie
- MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
- Snowflake Documentation: Planning for the deprecation of single-factor password sign-ins
- NIST: SP 800-63B Digital Identity Guidelines, Authentication
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- OWASP: Non-Human Identities Top 10
Related NHI Mgmt Group resources: the Infostealer Threat Guide, the Session Hijacking and Cookie Theft Guide, the Service Account Security Guide and the NHI breach prevention 30 and 90 day plan template.