Cryptographic tokens form the foundation of trust in Microsoft Entra ID. A failure in signature validation or key protection can bypass network perimeters, device compliance, and MFA.

Preface

Modern cloud architecture relies on the security of identity assertions. JWTs and SAML assertions underpin trust in Entra ID environments. The identity provider's token-signing control plane is the crown jewel of corporate security; securing it requires architectural isolation and rigid validation.

Customers do not control Microsoft's signing keys, but they do control how their own applications validate tokens, which issuers they trust, how long tokens live, and whether forged or misused tokens would be noticed. That is the scope of this article.

Problem

Storm-0558 showed the severity of control plane exploitation. An adversary acquired a private consumer Microsoft Account (MSA) signing key. Due to a validation flaw, enterprise authentication endpoints accepted tokens signed by that consumer key as valid for Entra ID apps such as Exchange Online, SharePoint, and Teams.

Forged access tokens bypass traditional authentication checks because receiving apps assume a trusted IdP signature implies complete validation. Overlapping consumer and enterprise validation paths meant the engine did not verify that the issuing key belonged to the enterprise tenant's key boundaries.

How token trust fails in practice

A resource server that receives a bearer token makes several separate decisions: is the signature valid, was it signed by a key belonging to the expected issuer, is the issuer the expected tenant, is the audience this application, and is the token within its validity window. Signature validation alone answers only the first question. Common failure patterns in custom applications include:

  • Accepting any key published in a shared or multi-tenant metadata document without checking that the issuer matches the key's scope.
  • Using the common endpoint metadata and then skipping issuer and tenant ID validation.
  • Not validating the audience, so a token issued for one API is accepted by another.
  • Hand-written JWT parsing that trusts the header's algorithm or fails open on errors.
  • Caching signing keys indefinitely, or never refreshing them, which breaks rotation and hides anomalies.

Storm-0558 was a failure in the provider's own validation, but the same class of mistake is common in line-of-business APIs, and there it is the customer's responsibility.

Solution

Align with NIST SP 800-204B and the CIS Microsoft 365 Foundations Benchmark, then apply layered controls:

  1. Standardize on modern SDKs: Require MSAL for custom and third-party integrations so signature and tenant-context validation is strict.
  2. Configure Configurable Token Lifetime (CTL): Reduce access token lifetime from 60 minutes to 15-30 minutes.
  3. Establish cryptographic isolation: Prefer HSM-backed signing in isolated confidential compute environments.
  4. Active signature auditing: Use Microsoft Sentinel to flag unrecognized or mismatching token key identifiers (kid).

Design guidance

Validation in your applications

MSAL handles token acquisition on the client side. On the API side, use maintained validation middleware such as Microsoft.Identity.Web or the platform's supported JWT handler, configured with:

  • Metadata from your tenant-specific endpoint, with automatic key refresh.
  • Explicit issuer validation, and an allow-list of tenant IDs for multi-tenant apps.
  • Audience validation against your application ID or URI.
  • An algorithm allow-list, lifetime validation, and authorization based on scp or roles claims, not mere token presence.

Token lifetime

By default, Entra access tokens are valid for a randomized period of roughly 60 to 90 minutes. Shorter lifetimes reduce the useful life of a stolen token but increase token requests. Apply short lifetimes to sensitive applications first rather than tenant-wide, and rely on Continuous Access Evaluation for near real-time revocation in supported clients. Note that refresh token and session lifetimes are governed by Conditional Access sign-in frequency, not CTL.

Issuers you operate

Where your organization runs its own token issuers, such as AD FS, a custom STS, or signing keys for internal services, store keys in HSM-backed Azure Key Vault or Managed HSM, restrict signing operations to a dedicated identity, separate production and test keys, and rotate on a defined schedule.

Implementation checklist

  1. Inventory every custom API and integration that validates Entra tokens, and record the library and version used.
  2. Replace hand-rolled or deprecated validation code with supported middleware.
  3. Review multi-tenant apps for explicit tenant allow-lists.
  4. Pilot a shorter access token lifetime on one sensitive application and measure impact.
  5. Log validated token metadata (iss, tid, aud, kid, appid) from your APIs to Log Analytics.
  6. Ensure mailbox audit events, including MailItemsAccessed, are enabled and retained; this was the signal that exposed Storm-0558.

PowerShell: Enforce Strict Access Token Lifetimes

This policy sets a 30-minute access token lifetime as the organization default. Test on a single application before setting IsOrganizationDefault, and remember a policy assigned directly to an application overrides the default. 

Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$params = @{
    Definition = @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:30:00"}}')
    DisplayName = "StrictAccessTokenLifetimePolicy"
    IsOrganizationDefault = $true
}
New-MgBetaPolicyTokenLifetimePolicy -BodyParameter $params

Monitoring and detection

Entra sign-in logs do not expose the signing key of tokens presented to your APIs, so key identifier auditing has to come from your own application telemetry. Once APIs log validated claims to a custom table, alert on anything unexpected: 

let KnownKids = dynamic(["<kid-1>", "<kid-2>"]);
let ExpectedTenant = "<tenant-id>";
ApiTokenAudit_CL
| where TimeGenerated > ago(1d)
| where Kid !in (KnownKids) or Tid != ExpectedTenant
| summarize Count = count(), Apps = make_set(AppId, 10) by Kid, Tid, Issuer

Maintain the known key list automatically from the tenant's published signing keys rather than by hand. In Entra logs, watch for tokenIssuerAnomaly risk events, sign-ins with an unexpected TokenIssuerType, and mailbox access from applications or IP ranges not seen before.

Common mistakes

  • Assuming that because Microsoft signs the token, every application validates it correctly.
  • Setting a very short tenant-wide lifetime without testing, then reverting under user pressure.
  • Treating CTL as a session control; it does not end a stolen refresh token or browser session.
  • Running mailbox auditing without the retention needed to investigate an incident months later.

Where to start

Find the applications in your estate that validate Entra tokens with custom code, and move them to supported middleware with issuer, tenant, and audience checks. Make sure mail access auditing is on and retained, then add token telemetry and shorter lifetimes to the most sensitive applications.