Microsoft disclosed on Wednesday that an internal red team exercise conducted in June reached production customer telemetry using credentials attached to application registrations nobody had touched in years. No customer data left Microsoft's environment and no external actor was involved. The company revoked 1,900 service principal credentials across its own tenants, changed the default client secret lifetime for newly created registrations from 24 months to 90 days, and published guidance urging customers to audit their own. The disclosure is voluntary and detailed, and it describes a problem that exists in essentially every large Entra tenant on the planet.
What the red team did
The team started from a position many attackers reach: read access to a source code repository containing historical commits. Rather than looking for currently valid secrets, which modern scanning catches, they enumerated application registration identifiers appearing in old configuration files and checked which still existed in the directory. Many did. Applications get created for a project, granted permissions, and then abandoned when the project ends, because deleting a registration requires knowing it is safe to delete and nobody ever knows that.
Of the registrations that still existed, a subset still held valid client secrets, because secrets created with long expiry outlive the projects that needed them. Of those, several retained Graph API permissions granted for the original purpose, including one with directory read access across a large tenant and another with access to a telemetry store. The chain from stale registration to production data required no vulnerability, no exploit, and no privilege escalation. It required only that cleanup had not happened.
Why this is everyone's problem
Entra application registrations accumulate the way files accumulate in a shared drive. Any developer with the default directory role can create one. Permission grants require admin consent for sensitive scopes and not for others, and the consent decision is made once at creation by someone reasoning about a project that no longer exists. There is no ownership expiry, no review cycle by default, and no signal that distinguishes an application in daily use from one last used in 2021.
Auditors have flagged this for years and organizations have largely not acted, because the remediation is unpleasant. Deleting a registration that turns out to be load-bearing breaks something in production at an unpredictable time, and the person who would know is gone. The rational individual response is to leave it alone, which aggregates into an organizational risk nobody owns. Microsoft's own tenant demonstrating the same pattern is useful mostly as permission for everyone else to admit it.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The changes Microsoft is making
New client secrets default to 90 days rather than 24 months, and the portal now warns when a longer lifetime is selected. That forces rotation, which forces someone to notice the application still exists. Microsoft is also shipping an inactive application report in the Entra admin center showing last sign-in per service principal, backfilled 12 months, which sounds obvious and was genuinely not available before in a usable form. A preview of automatic disablement after 180 days of inactivity is coming in the autumn, off by default.
The more consequential change is to permission grants. Starting in October, admin-consented Graph permissions on a registration with no sign-in activity for 12 months will require re-consent before they can be used again. That converts a permanent grant into a lease. Several enterprise identity architects called it the most useful thing Microsoft has shipped in this area in five years, with the caveat that it will break automation that runs annually, such as compliance reporting jobs, in ways that surface at the worst possible moment.
What customers should do this month
Run the inactive application report and sort by permission sensitivity rather than by age. An application with Directory.ReadWrite.All that has not signed in for two years is a different problem from a dormant registration with User.Read. Focus effort where the blast radius is large. For each one, the question is not whether it is used but whether anyone will notice if it stops working, and the fastest way to find out is to disable rather than delete, with a documented restore path.
Beyond cleanup, the durable fix is workload identity federation, which replaces client secrets with short-lived tokens issued to a workload based on its runtime identity. GitHub Actions, Kubernetes, and Azure workloads all support it, and it eliminates the long-lived secret entirely. Adoption has been slow because it requires changing deployment configuration rather than pasting a secret into a variable, which is a real cost and a smaller one than the alternative.
The pattern across cloud providers
AWS has the same problem under different names. IAM roles with trust policies referencing decommissioned accounts, access keys attached to users who left, and service-linked roles for services no longer in use accumulate identically. AWS added last-accessed information years ago and made it useful in 2023, and the same organizational dynamics keep the cleanup from happening. Google Cloud service accounts follow the same curve.
The structural issue is that creating an identity is easy and self-service while retiring one requires certainty nobody possesses. Until platforms make identities expire by default, with renewal as the affirmative action, the population will keep growing. Microsoft moving secret lifetimes to 90 days is a step in that direction and the industry will watch whether customers accept it or file support tickets asking to turn it off. The answer will tell you something about how seriously the market takes this.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Zero Trust
