Entra ID trades your credential for a token

A login credential in a cloud identity platform does not authenticate a person. It authenticates a claim, and the system converts that claim into a token. When an account signs into Microsoft Entra ID, the platform does not maintain an ongoing relationship with the human being. It performs a single resolution: it takes a presented secret, validates it against a stored value, and issues an artifact that represents the result of that validation. From that point forward, the artifact is the identity. Everything downstream consumes the artifact, not the credential, and certainly not the person.

That artifact is a bearer token. Under OAuth 2.0 and OpenID Connect, the protocols Entra ID implements, a bearer token means exactly what the word says. Possession is proof. The system that receives the token does not ask how it was obtained, whether the holder is the original subject, or whether the conditions that justified its issuance still hold. It checks the signature, checks the expiry, and grants access. Microsoft Graph, Exchange Online, and SharePoint Online do not re-authenticate the human on each request. They trust the token because the token carries the signature of an authority they already trust. The credential opened the door once. The token holds it open.

This is not a flaw in the sense that something is broken. It is the designed behavior of federated cloud identity. The entire value of single sign-on is that authentication happens once and the result propagates. A refresh token issued by Entra ID can, by default, remain valid across a rolling window of up to 90 days, silently reissuing access tokens so the user is not prompted again. The platform is optimized for exactly this: to resolve trust once and then spend that resolution as widely and as long as possible. A breach that begins with one compromised login is not a story about a weak password. It is a story about what the system does with the result of authentication after authentication is over.

The trust model underneath this was built on three assumptions, and each of them is a statement about time. The first is that authentication is an event with a durable result. The system assumes that the moment of sign-in produces a fact about the world that remains true for the lifetime of the token. Persistence is not a bug the designers tolerated. It is the feature they engineered. Refresh tokens, primary refresh tokens on joined devices, and long-lived session cookies all exist to extend the reach of a single successful authentication across hours and days, so the platform does not have to keep asking a question it believes it has already answered.

The second assumption is that trust is transferable without loss. A bearer token presented from a residential network in one country is, to the receiving service, identical to the same token presented from a datacenter in another. The token does not carry the context of its origin as a condition of its validity. It carries a subject, a set of scopes, an issuer, and an expiry. The OAuth 2.0 model deliberately decouples the artifact from the circumstances of its creation so that it can be replayed across services, tenants, and APIs without re-establishing trust each time. Transferability is what makes federation work. It is also what makes the token worth stealing.

The third assumption is that validity is a property of the token, not of the situation. Entra ID stamps an access token with a lifetime, commonly on the order of 60 to 90 minutes, and treats the token as valid until that clock expires or an explicit revocation reaches the right place. The assumption is that nothing meaningful changes between issuance and expiry, or that if it does, the short lifetime will absorb the difference. Validity is measured against a timestamp, not against the continuing truth of the conditions that produced the token. The system was built to answer one question at sign-in and to defend that answer until the answer expires on its own schedule.

What changed was none of these things about the attacker and everything about the assumption. The attacker capability required is not exotic. Phishing a session, replaying a stolen token, or riding a valid refresh token requires no zero-day and no privileged position. What changed is that the three assumptions stopped describing reality while the system continued to act as if they still did. The moment a credential is compromised, the fact the system resolved at sign-in becomes false. The human and the token holder are no longer the same party. But the system does not know this, because it was never designed to re-ask the question. It resolved trust once and inherited that resolution forward.

The divergence is silent because the system has no mechanism to notice it inside the window it already granted. A stolen refresh token continues to mint fresh access tokens. Each new access token is validly signed, correctly scoped, and unexpired. To Exchange Online and to Microsoft Graph, nothing is wrong, because nothing about the token has changed. The only thing that changed is the world outside the token, and the token does not carry the world. The platform did not re-evaluate trust when the conditions shifted. It propagated a decision made in the past into a present where that decision is no longer correct. Microsoft has built access not constrained at runtime Evaluation precisely because this gap exists, an acknowledgment that a token valid at issuance can become a token that should not be honored, and that the default model does not catch that transition on its own.

So the breach does not begin when the attacker acts. It begins when the assumption expires and the system fails to notice. One hacked login becomes a massive cloud breach not because the login was powerful, but because the login was the last time the system checked. Every access after that inherits the trust of that single moment. The credential is a key that was true once. The token is the system continuing to behave as though it is still true, across every service that agreed, in advance, to trust the issuer and stop asking.

Watch what the receiving service actually does when a stolen token arrives, and there is nothing to see. Microsoft Graph receives a request carrying a bearer token. It reads the issuer claim, confirms the token was signed by the tenant’s Entra ID signing key, checks the audience, checks the scopes, checks that the expiry has not passed. Every check succeeds, because every check is a check about the token, not about the party holding it. The service validates the reference to authority. It does not validate the integrity of the requester. The signature answers exactly one question: did the issuer this service already trusts produce this artifact. It does not answer, and structurally cannot answer, whether the artifact is in the hands it was issued to.

This is the substitution at the center of the failure. Validation of content was replaced by resolution of reference. Exchange Online does not verify that the human tied to the subject claim is present, or consenting, or even aware. It verifies that a trusted authority once said so, and that the saying has not yet expired. Identity of source stood in for integrity of content. Because Entra ID signed the token, and because Exchange Online trusts Entra ID, the token is treated as true. The chain of trust is a chain of references, and at no point in that chain does any component reopen the artifact to check whether the thing inside still corresponds to reality.

Nothing in this sequence is a bypass. A bypass implies a control was evaded, a wall climbed, a check skipped. No check was skipped. An attacker presenting a valid refresh token to the Entra ID token endpoint receives a fresh access token because minting access tokens from valid refresh tokens is precisely what that endpoint exists to do. Microsoft Graph honors the access token because honoring validly signed, correctly scoped, unexpired tokens is its designed function. The system did not fail to enforce its rules. It enforced them exactly. Under attack, the observable behavior of the platform is indistinguishable from its behavior under legitimate use, because at the level the system observes, there is no difference to detect. The refresh token minted an access token. The access token read a mailbox. Both events are, by the system’s own definition, correct.

This is why the telemetry stays green. The sign-in log shows a successful authentication followed by a series of successful token exchanges. A sign-in risk score computed at the moment of issuance can read low, because at that moment nothing observable was wrong. The record is complete and it is accurate, and what it accurately records is a correct system behaving correctly. The gap is not in the logging. The gap is that the fact worth knowing, whether the holder is the subject, is not a property the system measures, so it is not a property the system can emit. If you cannot see it, you do not control it, and the platform was never built to see this one.

Strip the identity language away and the mechanism is general. A system resolves a fact once, encodes the result of that resolution into a portable artifact, and thereafter grants action on the strength of the artifact’s provenance rather than the fact’s continuing truth. Execution follows reference, not verification. The artifact asserts that a trusted authority vouched for something at a past moment. The consuming system reads the vouching, confirms it came from an authority it trusts, and acts. Whether the underlying fact still holds is a question that lives outside the artifact, and therefore outside the decision.

The same mechanism runs the Domain Name System. A recursive resolver asked for an address does not, on every query, walk back to the authoritative nameserver to confirm the record still reflects reality. It answers from cache, and it keeps answering for as long as the record’s time to live has not elapsed. The TTL is the expiry stamp. The cached record is the token. The resolver executes on the reference it already holds, not on verification of the authoritative source, because re-verifying every answer would defeat the entire purpose of caching, in the same way re-authenticating every request would defeat the entire purpose of single sign-on. When the authoritative record changes, or when an attacker succeeds in seeding a false one, the resolver keeps serving the answer it resolved earlier. It is not malfunctioning. It is honoring a reference whose validity it measures by a clock, not by the state of the world.

In both systems the failure mode is identical, and it is structural rather than incidental. The efficiency that makes the system valuable is the same property that makes stale trust indistinguishable from current trust. Caching, federation, session persistence, signed assertions: each is a mechanism for not asking the same question twice. Each works by converting a live verification into a stored reference. And each inherits the same blind spot, that a reference is a record of a past resolution, and a past resolution cannot know about a present change. The artifact is faithful to the moment it was made. The system’s error is treating faithfulness to a past moment as truth about the current one.

Entra ID resolves trust at sign-in. It does not resolve it again until the token expires on its own clock. Between those two points the system is not verifying anything. It is replaying a decision.

One compromised login became a cloud breach because the login was never a door the attacker had to hold open. It was a decision the system agreed, in advance, to keep honoring.

The control exists. The outcome does not.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.