TL;DR - CISA and NIST released Interagency Report 8587 on 15 September 2026 with implementation recommendations for protecting tokens and assertions against forgery, theft and misuse. Microsoft published its own research on 9 September 2026 covering passkey-themed social engineering campaigns that end in cloud identity compromise, with activity observed since May 2026. The pattern in both is what makes token theft hard to see: no failed sign-ins, no impossible-travel alert, no MFA prompt for the user to deny. The attacker holds a token a legitimate user already earned. Detection depends on signals most SMB tenants do not alert on, particularly new authentication methods added to an account and sudden spikes in directory and file-activity APIs. What you need to do: alert on new authentication methods and application-consent grants this week, and treat a passkey support call as a session-theft attempt until the tokens are revoked.
The conversation I keep having goes like this. MFA is enabled across the tenant, conditional access is in place, and there was no failed sign-in spike. And yet somebody was reading the finance mailbox for three days before anyone noticed.
There is no single control failure to point at in that scenario, which is what makes it hard to explain upward. Your MFA did its job. It challenged a legitimate user, that user approved, and the session that resulted was used by somebody else. The prompt was answered correctly. The problem is what happened to the output of that prompt.
By the numbers
| Item | Detail |
|---|---|
| CISA/NIST report | Interagency Report 8587 |
| Released | 15 September 2026 |
| Full title | Protecting Tokens and Assertions from Forgery, Theft, and Misuse |
| Public comments incorporated | ~250 |
| Built on | NIST SP 800-53 Rev 5.1.1, control IA-13 |
| Industry contributors | Google, HashiCorp, IBM, Microsoft, Okta, OpenID Foundation, Oracle, AWS, Wiz |
| Microsoft research published | 9 September 2026 |
| Activity observed since | May 2026 |
| Initial access | Helpdesk impersonation by phone call and SMS |
| True objective | Usually not passkey enrolment |
What IR 8587 actually says
The report's subject is the token layer: the signed and encrypted assertions that carry identity between your identity provider, your applications, and your APIs. In a modern tenant, the password prompt is a small part of the authentication story. Most of what happens after that prompt is token issuance and token validation, and the tokens are what the applications actually trust.
CISA and NIST describe the report as expanding on NIST Special Publication 800-53 Release 5.1.1 and its IA-13 control, and it covers four areas:
- Architectural considerations for identity providers and authorisation servers
- Changes to key management, token verification and token lifecycle controls
- Guidelines for securing SSO, federation and API access that rely on digitally signed, asymmetrically encrypted tokens
- Principles for configurable, transparent and interoperable controls that support risk-informed, threat-adaptive decisions
The final report incorporated feedback from nearly 250 public comments on token validation, secrets management and detection at scale. It also reflects work through the Joint Cyber Defense Collaborative, including a technical exchange in June 2025 with more than 50 industry experts and a webinar in January 2026 to review the draft. The contributors list is a decent signal of the report's orientation: Google, HashiCorp, IBM, Microsoft, Okta, the OpenID Foundation, Oracle, AWS and Wiz all took part.
Chris Butera, CISA's Acting Executive Assistant Director for Cybersecurity, framed the problem in the release: identity is the new perimeter, and the tokens and assertions behind it are attractive targets for sophisticated adversaries. The report's stated goal is to give agencies and cloud providers a practical path to harden token issuance, verification and management so that a stolen or forged credential cannot become a foothold across the enterprise.
Two things about that framing are worth taking seriously from an SMB seat.
The report is written for federal agencies and cloud service providers. It is not a checklist for a 40-person business running Microsoft 365 with cloud-only identity. You are not the intended reader, and you should not try to implement it directly.
The architectural material still transfers, because the problem is not a federal problem. Every tenant that uses SSO, federation or API-based access has a token layer, and every token layer has the same properties the report describes. The parts that matter most for a small tenant are the detection sections, and CISA's emphasis that detection at scale was one of the three themes the public comments centred on.
The Microsoft research fills in the other half
Where the CISA and NIST report is architectural, Microsoft's 9 September research is operational, and together they describe the same attack from two ends.
Microsoft Security Research describes active cloud-based intrusions spanning multiple accounts where unusual sign-ins are followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs. The activity has been observed since May 2026, and the assessment is that the sequence is consistent with automated collection from compromised cloud identities using proxy-associated infrastructure.
The initial access step is the part worth reading closely, because it is not a technical exploit.
It starts with a call or message to a user's personal mobile number from somebody claiming to be from the organisation's IT helpdesk. The caller creates urgency: a passkey, MFA or SSO configuration needs updating immediately to avoid disruption. The employee is directed to a site that resembles a Microsoft sign-in experience, and the link often arrives by SMS to a personal phone rather than through a corporate channel.
Here is the detail that changes how you train staff. Passkey enrolment is frequently not the attacker's objective. The passkey narrative is a pretext to walk the victim through adversary-in-the-middle phishing, where the attacker captures credentials and session tokens, or through a device-code authentication flow, where the victim unknowingly authorises access on the attacker's behalf.
That means the standard advice, "never set up a passkey because someone called you", is incomplete.
The passkey conversation is the delivery vehicle. The thing being stolen is the session.
Why your current alerts miss this
Most SMB tenants have alerting that maps to old attack patterns, and the signals token theft produces sit outside those maps.
Failed sign-ins are the wrong signal. Credential stuffing and password guessing produce failed authentication attempts. Token replay produces successful ones. The attacker is not guessing anything. They are presenting a token the platform considers valid, from infrastructure that resolves to a plausible location, often through proxy services that make the originating address look ordinary. Your failed-login alert stays flat through the entire intrusion.
Impossible travel depends on your impossible-travel settings. Attackers using proxy infrastructure specifically work around geographic anomaly detection. If the proxy egress is in the same country as the user, the anomaly never fires.
MFA fatigue detection does not apply. The classic MFA bombing pattern is a user receiving repeated prompts and eventually approving one. In an AiTM or device-code flow, the user approves exactly one prompt, which is what they thought they were doing, and the approval is valid. There is nothing anomalous about the authentication event itself.
The user has no reason to report anything. From their perspective, they got a call about a security update, followed the instructions, and it worked. There is no obvious failure for them to escalate.
The upshot is that the entire intrusion runs inside your logs as successful events, and the only thing separating it from normal activity is the sequence that follows.
The signals that do catch it
Microsoft's write-up points at the sequence rather than any single event, and it is explicit that domains, IP addresses and hosting providers change quickly while the sequence is durable. That is what makes it usable as a detection strategy: you stop hunting for a specific indicator and start alerting on a shape.
The shape is identity compromise, then persistence, then reconnaissance, then content discovery, then exfiltration. In tenant terms:
- An unusual sign-in, which on its own proves nothing.
- An authentication method added to the account. A new passkey, a new authenticator registration, a new phone number, a new device. This is the persistence step, and it is the single highest-value alert for most small tenants because legitimate users rarely change authentication methods without a support ticket.
- A spike in directory-read activity. Microsoft describes high-volume Microsoft Graph activity. In practice this looks like one account enumerating users, groups, mailboxes and permissions far faster and more broadly than a human would while doing their job.
- Bulk file access. SharePoint and OneDrive downloads at a volume and in a pattern that does not match the account's normal behaviour.
- Mail collection through REST APIs. Email accessed programmatically rather than through a client, which frequently bypasses the assumptions behind mailbox activity baselines.
- Session revocations as a response, not a discovery. Microsoft's mitigation guidance is to investigate across identity, Graph, SharePoint, OneDrive and Exchange signals, then revoke sessions and remove unauthorised authentication methods for confirmed compromises. Removal matters as much as revocation, because revoked sessions are meaningless if the attacker registered a new credential on the way in.
If you map those six against what your tenant currently logs, the gaps usually appear at items two and three. Sign-in logs everyone has. Authentication-method change logs and directory-audit volume baselines are the two that most small tenants have the data for and no alerting on.
What to do this week
- Check whether you can see authentication-method additions at all. In Microsoft Entra, the audit logs carry "Add authentication method" and related operations. If you have never queried them, do that before you build anything. The data is usually there and the alerting is what is missing.
- Create one alert on authentication-method changes. Send it somewhere a human reads. A new passkey or authenticator registration on an account that did not raise a support ticket is worth the interruption. False positives will come from legitimate device changes, and that is an acceptable trade for a signal that catches the persistence step.
- Establish a baseline for directory-read volume per account. You do not need anomaly detection software. A weekly count of Graph directory operations by account, reviewed by a human, will surface the accounts doing reconnaissance, because the volume stands out against their own history.
- Review who can see and manage authentication methods. The helpdesk impersonation works because the story is plausible. If your service desk can reset MFA or register an authentication method on a user's behalf, confirm the process requires identity verification through a channel the caller cannot control, and that the actions are logged with the operator's identity.
- Decide your session revocation procedure before you need it. Know the command, know who is authorised to run it, and know what happens to the user's access afterwards. An incident is the wrong time to discover that revocation requires an approval chain nobody has documented.
- Cover device-code flows as a control point. Device-code authentication exists for legitimate reasons and is abused precisely because it moves authentication onto a device the attacker controls. If you do not have a business requirement for it, restrict it. If you do, alert on it.
- Train on the sequence, not the artefact. "We will never call you about passkeys" is a fragile rule because the attacker will change the pretext. The durable version is: we will never ask you to authenticate through a link we send you, and any call about your account ends with you contacting us through the service desk number you already have.
- Check your personal-device exposure. The initial contact frequently goes to personal mobile numbers, which means staff contact details outside the corporate directory are part of the attack surface. You cannot control those, but you can tell staff that an unexpected call about their work account on a personal phone is a scenario worth stopping on.
Frequently asked questions
What is a cloud identity token in simple terms? When you sign in, the identity platform issues a token that says who you are and what you can access. Applications trust the token rather than re-checking your password. Stealing a valid token lets an attacker act as you without knowing your password or triggering another MFA prompt.
Does token theft mean our MFA is useless? No, and the distinction matters. Token theft does not defeat MFA. It exploits the fact that MFA already happened legitimately. The control worked; the output of the control was taken. This is why the response is session and credential handling rather than a different MFA product.
How is adversary-in-the-middle phishing different from normal phishing? In normal phishing the attacker collects credentials and then tries to use them, which triggers an MFA challenge they have to get past. In AiTM the attacker sits between the user and the real sign-in page, so the user authenticates against the real service and the attacker captures the resulting session token alongside the credentials.
What is device-code phishing? Device-code authentication lets a user authorise a session on one device by entering a short code on another. An attacker who starts the flow can send the victim the code and have them authorise the attacker's session, which appears legitimate in the logs because the victim did approve it.
Why does Microsoft say passkey enrolment is not the objective? Because the passkey story is the most convincing pretext available right now. It gives the caller a reason to walk the user through an authentication flow on the spot. The enrolment is not what the attacker wants; the session or credential captured during that flow is.
Is IR 8587 worth reading for a small business? It is written for federal agencies and cloud providers, so it will not map cleanly onto a small tenant. The architectural and detection sections describe problems you have, and it is a free authoritative reference to point at when you need to justify identity work to someone above you.
What is the single highest-value change we could make this week? Alerting on authentication-method additions. It is the persistence step, it is a low-volume signal, and legitimate changes usually correlate with a support ticket you can check against.
My Take
The part of this I keep coming back to is that the CISA report and the Microsoft research landed six days apart and describe what is effectively one problem, and the industry will read them separately.
The report is written for agencies and cloud providers, so most small-tenant operators will see the audience and stop reading. The research is a technical write-up with an attack chain, so most small-tenant operators will see the length and stop reading. The overlap in the middle, which is the part where you find out that the signals you log are not the signals that catch this, sits between the two and belongs to neither document's stated audience.
I think that gap is going to matter more each year, because the economics point one way. Credential stuffing requires guessing something, which means effort per account and defences that work. Token theft requires capturing one session, and the resulting access is indistinguishable from the legitimate user for as long as the token lives. Every time a platform makes token handling more convenient, the value of the token goes up.
The practical consequence for an ANZ SMB is narrower than the documents suggest, and it is why I keep pushing one alert rather than a programme. You are not going to implement an identity hardening framework this quarter. You can, this week, find out whether your tenant records authentication-method changes, and put a notification on them. That single signal is the difference between discovering a compromise during the persistence step and discovering it after the mailbox has been read for three days.
The uncomfortable part of the Microsoft research is the attack surface it names. A phone call to a personal mobile, about a work account, from someone claiming to be the service desk. There is no product that solves that. There is a script your service desk follows and a habit your staff form, and both of them depend on somebody having decided that the conversation is worth having before the call arrives.
Further reading
- CISA: CISA and NIST Release Guidelines to Protect Federal Cloud Identity Systems from Token Theft, Forgery, and Misuse (15 September 2026)
- NIST: Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- NIST: Special Publication 800-53 Release 5.1.1 (control IA-13 is the device and service authentication hook)
- Microsoft Security Blog: Passkey-themed social engineering leads to identity and cloud compromise (9 September 2026)
- Microsoft Learn: audit log activities reference for Microsoft Entra
- SecureInSeconds: The MFA fatigue playbook and why approving once is the whole attack
- SecureInSeconds: What went wrong in an MFA rollout and the order to fix it
- SecureInSeconds: CISA left leaked passwords on GitHub - the credential hygiene read-across
Mathew Clark / Founder, SecureInSeconds / Currently: convinced that the highest-value identity alert in most small tenants is sitting in data they already collect and nobody has switched on
