The Keys You Cannot See

Microsoft published a post yesterday saying that an actor it tracks as Storm-0558 had been reading customer mail. The dates are the part worth sitting with. Access began on 15 May. The investigation opened on 16 June, on a report of anomalous mail activity from a customer. About twenty-five organizations, government agencies among them, had somebody in their mailboxes for roughly a month, and what ended it was a customer noticing an oddity in its own records.

The method is one sentence and it deserves to be read slowly. The actor held a Microsoft account consumer signing key, which the post describes as acquired, and used it to forge authentication tokens for Outlook Web Access in Exchange Online and for Outlook.com. Not stolen sessions. Not phished passwords. Tokens minted on the attacker's side of the transaction, correctly signed, handed to a service that checked the signature and found it good.

What follows is uncomfortable in a specific way, because there is no misconfiguration here to point at. The post says mitigation is complete and no customer action is required, and both halves are true: Microsoft blocked tokens signed with that key, replaced the key, and shipped hardening into its identity validation libraries. Nothing the affected organizations did caused this, and nothing they could have done would have prevented it. That sentence is meant to reassure. Read it again.

So here is the claim the rest of this is about. In a managed identity provider the signing key is the entire trust boundary, and it is the one component a customer can neither inspect, rotate, nor audit. Every other control you bought sits downstream of it. Which means the response available to you is not better monitoring of the edge. It is shrinking what a valid-looking token can reach once it is already inside.

A token is a signature over a claim. The thing your application receives is a small document saying who the bearer is, which tenant they belong to, what it is good for and when it expires, with a signature across the whole of it. The relying party does not phone the issuer to ask whether the document is real. It checks the signature against a public key it already holds. Offline verification is the feature, and it is what lets federated identity scale.

The public half is published deliberately. Every issuer serves a discovery document and a key set at a well known address, listing its current signing keys by identifier so any service anywhere can fetch and cache them. Anyone can read it, and that is correct. The entire secrecy budget of the system rests on the private halves inside the provider, and the published document is just the list of keys your services agreed in advance to believe.

There are four verbs you do not get. You cannot inspect it, in the sense of having a fingerprint you could compare against an expectation. You cannot rotate it, because nothing in any tenant admin surface offers that. You cannot pin it, saying that only this one key may sign for my organization. And you cannot get an attestation about where it lives, what module holds it, or which internal systems are able to ask it for a signature.

One root signs for every tenant. A multi-tenant identity provider signs for all of its customers from a small set of keys, which is the only way the arrangement is operable. The consequence is that tenant separation is application logic sitting on top of a shared cryptographic root rather than a cryptographic boundary in its own right. Microsoft's post says there is no indication that other keys were used by this actor, and I believe it. A statement about indications is still not a statement about reach.

Compare it with a key you actually hold. An internal certificate authority has a fingerprint you can publish, an inventory of who may invoke it, a hardware module with usage logs, and a rotation schedule you set. So does an SSH certificate authority, or the key signing your own release artifacts. None of that is exotic. None of it is available for the key that signs your employees into their mail every morning.

Picture a well run tenant. Multi-factor authentication everywhere, ideally phishing-resistant. Conditional access requiring a compliant managed device on a known network, stepping up on anything unusual. Risk detection watching for the impossible journey between two countries in ten minutes. Session lifetimes tuned so a stolen cookie ages out. That is a genuinely good posture, and somebody spent two years getting it approved.

Every one of those is a condition evaluated by the issuer at the instant a token is created. A forged token is not created by the issuer. It appears, already signed, at the door of the resource. There is no sign-in event to score, because there was no sign-in. There is nothing in the risk engine, nothing in the conditional access evaluation record, and nothing in the sign-in log, which is a log of the front door for a visitor who came through the wall.

Continuous access evaluation does not close this either, though it is the mechanism people reach for. It exists to cut a live session short when something changes: the password was reset, the account was disabled, the risk score moved. Those are all events on the issuer's side of the relationship, and they belong to a session the issuer created and knows about. There is no revocation signal for a session that was never issued, because there is nothing to revoke it against.

The framing that makes this hard to see is that authentication is either strong or weak, and strong is what you buy. Strength is a claim about how expensive it is to become a legitimate user. It says nothing about a path that skips the step of becoming one. Every control operating before a token exists is invisible to an attacker who starts afterward, and almost every control you can name operates before a token exists.

The customer found it, not the provider. On Microsoft's own account the investigation began on 16 June from a customer report of anomalous mail activity, and that is the most instructive line in the post. The party with the least visibility into the identity platform produced the signal. It did so by looking at records of its own data being read, not at records of anyone signing in, which is the only class of evidence that still means anything once the authentication layer cannot be trusted.

Data access, not sign-in, is the surviving evidence class. If a token can be forged then the sign-in log describes a population that no longer includes your adversary, and the only remaining question is what was read. In Exchange Online that question is answered by an audit event recording that a mailbox item was accessed, per user, per session, with enough detail to bound the exposure. It is the difference between knowing who came in and knowing what left, and only one of those is useful afterward.

That event sits in the upper tier. Microsoft's published comparison of Purview Audit (Standard) and Audit (Premium) puts the forensic events - when users access mail items, when they forward them, what they searched for in Exchange Online and SharePoint - in the premium tier, which needs an E5-class license or an add-on. The documentation is explicit that the license is what causes the records to be generated. Without it the evidence is not hidden from you. It is not written down.

Retention is the other column of the same table. Audit (Standard) keeps records for 90 days; retention beyond that, up to a year, is a premium capability with its own retention policies. Here the window was survivable, since about a month of access was disclosed within four weeks of discovery. An intrusion found eleven months late would fall entirely off the end of a standard tenant's history, and the report you could write about it would begin and end with the word unknown.

Evidence is a product, and that is the transferable part. This is not particular to one vendor. Every managed platform decides which of its internal events a customer may see, at what price and for how long, years before anyone needs them. I do not know what logging the affected organizations had, and the point does not depend on it: the audit schema and its retention are part of the security architecture, settled by whoever signs the order form.

The available move is unglamorous. You cannot make a forged token invalid, because validity is decided by a signature you do not control. You can make a valid token worth less. Everything that happens after a token is presented - which application it maps to, what that application is permitted to read, whose data is in reach of that permission - is an authorization decision inside your tenant, and it is the only part of the path that is genuinely yours.

Concretely that means scope, and it means paying attention to the least popular kind of configuration there is. An application granted mail read permission across the tenant is exactly one valid token away from every mailbox in the organization. The same grant restricted to the mailboxes it actually needs is one token away from those. Application access policies exist for this and they are tedious to maintain, and tedious maintenance is the entire difference between an incident and a disclosure.

The larger version is that not everything belongs in one identity domain. The material that would end you if it were read can sit behind a second, independently rooted check: a separate tenant, an authorization service with its own credentials, an approval a bearer token alone does not satisfy. This is friction, it is unpopular, and most organizations have spent a decade removing exactly this friction under the banner of single sign-on. That consolidation was correct for the threat model everyone had, and it concentrates the consequence of the one they did not.

What I would not conclude is that you should run identity yourself. Taking the key back means taking the job of protecting it, at a scale where you will do it worse than a company with a team dedicated to nothing else, and I would still choose the managed service tomorrow. The thing to stop is the pretending. Every architecture diagram I have drawn treated that boundary as solid, and it is the one line on the page nobody in the room could have verified.

Write down what one valid token reaches. Enumerate the tenant-wide application permissions, the service principals holding mail or file access across every user, and the integrations that were granted admin consent years ago by somebody who has left. That list is the real blast radius of a forged token, it is almost always longer than anyone expects, and hardly any organization has ever produced it on purpose.

Scope application permissions to mailboxes, not tenants. The mechanism to bound an application to a specific set of mailboxes already exists and is largely unused, because the tenant-wide grant is one click and the bounded one is a policy somebody has to own. It converts a permission that reaches everything into a permission that reaches a department, which is the whole of what defense in depth means here.

Find out which events your license generates. Not which ones the portal will search for, which ones are written at all. That answer cannot be changed retroactively, so the time to learn it is on an ordinary Tuesday rather than during an investigation when the gap in the record is the finding. It takes an afternoon and it is the cheapest thing on this list.

Put one check somewhere a token does not reach. For the small set of actions where being wrong is unrecoverable - exporting the customer database, changing where payments go, minting new administrative access - require something that is not a bearer credential. An out-of-band approval, a second person, a signature over the request itself. It is slow on purpose and there should not be many of them.

Ask the questions that currently have no answers. How often are the signing keys rotated. Is there any published fingerprint or transparency record a customer could check. What is the retention of the access logs the provider keeps about your tenant, as opposed to the ones you keep. Most of these have no answer today, and asking them during procurement is the only mechanism by which they ever acquire one.

I want to narrow this, because it would be easy to read as an argument that federated identity was a mistake, and I do not believe that at all. Offline signature verification is why a browser can prove who you are to forty services without any of them ever holding a password, and the property that makes a forged token indistinguishable is the same property that makes the arrangement work. Microsoft also published while the question of how the key was acquired was still open, which is not the comfortable choice.

What survives is smaller and harder to argue with. Somewhere in every system there is a component delegated so completely that you have no way to check it, and the tell is not that it looks risky. The tell is that you have no procedure at all for what you would do if it were wrong. For most of us that component signs a token every morning, in a building we will never enter, with a key whose fingerprint we would not recognize if it changed under us tonight. The only honest posture left is to assume the signature is good and build as though the bearer might not be.