Research: Identity Risk in the Modern Enterprise

Summary

Identity risk in the enterprise concentrates in a small number of recurring conditions rather than being spread evenly. Across the documented cases reviewed here, the same five conditions appear: entry through an identity outside the controls, privilege held by applications as well as people, credentials that stay valid long after exposure, missing context checks around access, and trust relationships that turn one identity into many.

Scope and method

This is a desk analysis. No survey, telemetry or proprietary dataset was collected, and the report makes no claim about how common any condition is across the market. The method was to read primary, attributable sources that describe identity as the entry or escalation path, extract the mechanisms they document, and compare them for repeating patterns.

Sources reviewed: Microsoft’s published account of a nation-state intrusion into its corporate environment; Mandiant’s analysis of a data theft and extortion campaign against customers of a cloud data platform; the OWASP Non-Human Identities Top 10; and the MITRE ATT&CK technique for valid accounts. Statements that come directly from these sources are labeled as documented. Statements that are the author’s reading are labeled as interpretation. Anything that would need an organization’s own data to confirm is labeled as a hypothesis.

Findings

1. Entry came through identities outside the controls

Microsoft reported that the actor used password spray attacks to compromise a legacy, non-production test tenant account that did not have multi-factor authentication enabled. Mandiant reported that the accounts used in the Snowflake customer campaign did not have multi-factor authentication either, so a valid username and password was enough.

Interpretation: in both cases, a baseline control existed in the enterprise but did not reach the identity that was attacked. The weak point was coverage, not the strength of the control. Test, legacy and forgotten accounts are where coverage tends to run out.

2. Applications held privilege, and attackers used it

In the Microsoft case, the actor found and compromised a legacy test OAuth application that had elevated access to the corporate environment. It then created additional malicious OAuth applications and a new user account to grant consent to them, and used the legacy application to grant a role that allows access to mailboxes. OWASP lists overprivileged non-human identities as one of its ten risks.

Interpretation: privileged access reviews that cover administrators but not application registrations and service identities leave a gap that attackers have shown they can use. An application that can grant access to others is closer in power to an administrator than to an ordinary account.

3. Stolen credentials stay useful for a long time

Mandiant found that credentials harvested by infostealer malware were still valid in some cases years after theft, because they had not been rotated or updated. OWASP lists long-lived secrets and secret leakage among its ten risks.

Interpretation: the time between credential exposure and credential abuse is a variable the defender controls. Rotation and revocation shrink it. Without them, a single infection on a system outside the enterprise’s control becomes a latent entry point.

4. Authentication strength is one control, access context is another

Mandiant named a third contributing factor beside missing multi-factor authentication and unrotated credentials: the affected instances had no network allow lists limiting where access could come from.

Interpretation: a valid credential used from an unexpected place is still a valid credential unless something asks where it is coming from. Strong authentication and restricted access context cover different failure modes. Neither replaces the other.

5. Trust relationships are the attack path

MITRE ATT&CK describes the use of valid accounts as a technique that adversaries use for initial access, persistence, privilege escalation and defense evasion. It includes sub-techniques for cloud accounts and default accounts. In the Microsoft case, the chain ran from a test account to an OAuth application to new applications and a new user, each link a consent or delegation rather than an exploit.

Interpretation: these paths do not involve malware, so detection that looks for malicious files will not see them. They show up as unusual consent grants, role assignments and authentications. Assessing identity risk therefore means mapping what each identity can grant, not only what it can access.

A way to assess and prioritize identity risk

The findings support a five-question test that can be applied to any identity population, human or non-human. It is an assessment method, not a scoring model, and it should be run against the organization’s own data.

Priority follows privilege first, weakness second. In order:

1. Identities, human or non-human, with high privilege and any failed answer above.

2. Identities that can grant access to others, such as application registrations with consent or role-assignment power.

3. Identities with standing access that no one owns or has used.

4. Identities whose credentials are known to be exposed or are old enough that exposure cannot be ruled out.

5. Everything else, handled by baseline policy.

Interpretation: this ordering treats reach as the multiplier. A weak control on a low-reach identity is a hygiene issue. The same weakness on an identity that can grant access is a route to the whole environment.

Limitations

• Small, selective sample. Public, well-documented incidents are skewed toward large organizations that disclose detail. They show mechanisms and cannot show how common those mechanisms are.

• Source perspective. Incident accounts come from the investigators or the affected party, and each has its own vantage point.

• OWASP is consensus, not measurement. The Non-Human Identities Top 10 reflects community judgment about risk. It does not report measured frequency.

• No quantification. The prioritization order is analytical judgment and has not been tested against outcomes.

• What would strengthen it. Data from an organization’s identity provider, cloud IAM and secrets scanning, with a defined sample, collection date and population, would turn several interpretations here into testable claims.

Implications for security leaders

• Extend baseline controls to every environment. Test, legacy and non-production identities need the same authentication and access-context requirements as production.

• Bring applications into privileged access governance. Application registrations and service identities that can grant or escalate access belong in the same review process as administrators.

• Shorten the exposure window. Set rotation and revocation expectations for credentials and tokens, and measure them.

• Govern consent and delegation. Treat new consent grants and role assignments as events worth monitoring and approving.

• Measure inside your own estate. Track proportions and trends against your own baseline. Cross-organization comparisons need a shared definition of identity that rarely exists.

How the identity population grows, and why measuring that growth is its own problem, is covered in the companion report, Human and Non-Human Identity Growth.

Sources

Microsoft Security Blog, Midnight Blizzard: Guidance for responders on nation-state attack. microsoft.com

Google Cloud, Mandiant, UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion. cloud.google.com

OWASP, Non-Human Identities Top 10. owasp.org

MITRE ATT&CK, Valid Accounts (T1078). attack.mitre.org