The identity attack surface is the total set of access that identities in an environment currently hold and could exercise without asking anyone for permission. It measures standing capability, not account count. Two organizations with identical account totals can differ by an order of magnitude in exposure, depending on what those accounts already reach.
That distinction changes what reduction means. Deleting dormant accounts can reduce risk, but account count alone says little about the remaining exposure. An account with no permissions adds nothing to the surface, while an active service account holding administrative rights across a storage tier adds a great deal. Clearing the first and leaving the second moves a number on a dashboard and leaves the exposure where it was.
Getting the measurement right is most of the work, and it starts with what the inventory is missing.
Why Identity Has Become the New Attack Surface
The phrase gets repeated until it stops meaning anything, so it is worth rebuilding the argument from mechanics.
In an on-premises estate, reaching a system required network position. Access control arrived in layers: a network path, then a host, then an application credential. Each layer was a separate obstacle and identity was the last one. In a SaaS and cloud estate, those first two layers often belong to the provider rather than the customer. The application answers from anywhere, and authorization becomes the control the customer can influence most directly. Identity is no longer the last obstacle. It is often the decisive one.
How much standing authorization exists sets the size of the resulting exposure, and that number grew quietly for a decade. Every project that granted a role, every integration that created its own credential, every migration that issued a key, and every incident that elevated somebody added to it. Few of those additions carried an expiry, and the ones that did were often extended.
Identity attack surface management is the practice of measuring that accumulation and reducing it on purpose, instead of learning its shape during an incident.
The Anatomy of an Identity-Based Attack
An identity intrusion runs in three phases, and only the first looks like an attack.
Acquisition. The attacker obtains a working credential. Phishing, an adversary-in-the-middle proxy that captures a session cookie, credential stuffing against an application with no rate limiting, a key committed to a repository, or a help-desk call that ends with a new authentication method registered on the account. The method varies and the result is the same. The attacker now authenticates legitimately.
Consolidation. Most defenses miss this phase because nothing in it is anomalous at the protocol level. MITRE ATT&CK catalogs the two dominant behaviors. Account Manipulation (T1098) covers any action that preserves or modifies an adversary's access to a compromised account, including changes to credentials and permission groups, and MITRE maps the technique to both persistence and privilege escalation. Its sub-techniques read like an inventory of the surface itself: additional cloud credentials, additional cloud roles, SSH authorized keys, and device registration.
The second behavior is Modify Authentication Process (T1556), which covers changing how authentication works and carries documented sub-techniques for multi-factor authentication, hybrid identity, and conditional access policies. Both techniques operate on identity configuration rather than on hosts or networks. Both are additions to the attack surface, made by the attacker.
Exercise. The attacker uses what the identity already had, and standing access converts into consequence here. An account with read access to one repository yields one repository. A role that any principal in the subscription can assume exposes everything that role can reach. Nothing in this phase requires a new technique, which is why reduction beats detection at this point. The phase is short, quiet, and made entirely of permitted operations.
Acquisition is hard to prevent and consolidation is hard to detect. That leaves the size of the exercise phase as the variable a defender actually controls.
Common Identity Security Gaps Organizations Face
Five gaps recur across environments, and they share a shape. Each one is a population that some system was never told to care about.
Identities outside the identity provider. Local application accounts, database logins, cloud-native users created by a console click, and API clients registered inside a SaaS tenant. They authenticate, they hold permissions, and they appear in no governance workflow.
Non-human identities with no owner. A service account created for a 2019 migration still holds a credential and a permission set, and nobody is accountable for it. Orphaned accounts of this kind survive reviews because a review asks an owner to attest, and there is no owner to ask.
Entitlements granted through relationships rather than assignments. A group grants a role. A role trusts a principal. That principal gets assumed by anything running in the account. No single record shows the resulting reach, so no single review covers it.
Authentication methods as an unwatched inventory. Which methods are registered to which accounts is access-relevant data. Most environments treat it as help-desk operational data and leave it out of review entirely, which is what makes T1556 practical.
Duplicate identities for the same person. Identity sprawl means one person holds accounts in six systems under four naming conventions. Governance applied to two of the six is not governance.
The common thread decides the remedy, so it is worth stating plainly. An access review certifies what somebody enumerated. Every gap above is invisible to a review no matter how rigorously the review runs.
Discovering Hidden Identity Risks Across the Enterprise
The tools for identity-based attack surface insights fall into three groups, and they answer different questions.
| Tool group | Question it answers | Best for | Evaluate |
|---|---|---|---|
| Directory and IdP reporting | What exists in the directory and identity systems already connected | A starting inventory and coverage of the federated estate | Whether it reports accounts that authenticate locally instead of through the IdP |
| Cloud entitlement analysis | What a principal can reach through roles, trust policies, and role assumption | Cloud-heavy estates where access is assumed rather than assigned | Whether it resolves multi-hop paths, not only direct grants |
| Cross-system identity graphs | Who exists across connected systems, and how each grant was made | Estates with acquisitions, legacy directories, or large contractor populations | How the product resolves accounts belonging to one person or workload into a single record, and what remains for a human to adjudicate |
Directory reporting is accurate and bounded by definition. Treat it as a starting inventory, not as a complete one. Cloud entitlement analysis is where relationship-derived access becomes visible, and it is the highest-yield discovery in most cloud-heavy estates. A cross-system identity graph can resolve the duplicate-identity problem and turn per-system findings into a defensible surface measurement.
Whatever the tool, discovery should return four lists: identities with no owner, identities holding standing privileged access, identities that have not authenticated inside a window your policy calls stale, and access paths that reach sensitive resources through more than one hop.
Decision rule: start discovery with the systems that issue credentials, not the systems that hold data. It is usually the shorter list, and every credential-issuing system left out creates a blind spot for the controls downstream.
Reducing Attack Paths Through Identity Security Controls
Identity attack surface reduction works on three variables: how many identities hold access, how much access each one holds, and how long they hold it. The third is usually the cheapest to change and the most often ignored.
Convert standing access to time-bound access. An entitlement that exists only during a task cannot be exercised outside it. Start with roles that are broadly scoped and rarely used, where risk removed per unit of disruption runs highest. Just-in-time access applied to those roles shrinks the exercise phase in a way detection alone cannot.
Remove unused permissions on a schedule your risk policy sets. Usage data is available in most cloud control planes and most SaaS admin APIs. A permission unused across a meaningful window is a strong removal candidate, but usage evidence still has to be checked against seasonal work and undocumented dependencies. Resist a universal interval here, because the right window depends on how seasonal the work is.
Break the relationship chains, not only the assignments. Removing a user from a group achieves nothing if the group still grants a role that any principal can assume. Reduction has to operate on the path, which is why the discovery step has to model relationships.
Treat authentication-method changes as privileged operations. Registering a new method on a privileged account deserves the scrutiny of granting privileged access, because it can give another actor everything the account already holds. This closes the most practical route to elevated access that leaves no anomalous login behind.
Give every identity an owner, including the ones nobody wants. Ownership is the precondition for every other item on this list, because unowned access rarely gets removed. Few people volunteer to be the one who broke a job whose purpose is undocumented.
Decision rule: when a finding cannot be remediated because the dependency is unknown, time-bound the access instead of accepting it. A permission that expires and gets renewed by request produces the dependency map the original investigation could not.
Protecting Human and AI Agent Identities
The non-human identity attack surface grew fastest and gets measured least, for a structural reason rather than a technical one.
Human identity management runs on employment events. Somebody is hired, changes role, and leaves, and each event triggers a provisioning action and a review. Machine and agent identities have no equivalent. A service account starts with a ticket and ends when somebody deletes it, which in practice is rare. An AI agent gets created by an engineer, granted an OAuth scope into production, and left running with no owner recorded anywhere. Certificates, keys, and agents have no leaver event.
That exposure now carries a price. IBM's 2026 Cost of a Data Breach research found one in four malicious breaches were AI-enabled, a 56% increase year over year, at an average cost of $6 million against a global average of $4.99 million. The same study reported that more than 20% of organizations experienced a breach targeting AI models or applications, most often through compromised APIs, applications, or plug-ins (27%) and cloud misconfigurations affecting AI workloads (27%). Those are failures in the systems surrounding the model, where APIs, integrations, plug-ins, cloud configuration, and identity controls determine how far an attacker can reach.
Three controls apply to this population, and they mirror the human ones with the lifecycle assumptions removed:
- Ownership assigned at creation, because no HR lifecycle event will assign it later.
- Credentials scoped to the task and expiring with it. A static key held by an unowned workload is the purest form of standing access, and the same logic governs machine identities and their credentials.
- Discovery that runs continuously, because this population changes at the rate of engineering work rather than the rate of hiring.
A service account treated only as infrastructure may get rotated and monitored without ever receiving an owner or an access review. Treated as an identity, it can inherit the ownership, lifecycle, and governance controls already used for people.
How NewCore Helps Secure the Identity Attack Surface
Nobody reduces a surface they have only partly enumerated, and the unenumerated part is rarely the employee accounts. NewCore starts from the identities no HR event ever created: the service accounts, workload credentials, and agents that accumulate standing access with nothing in the lifecycle to take it back.
- Identity Discovery: connects HRIS, directories, IdPs, IGA, PAM, cloud, SaaS, and AI platforms, then continuously indexes identities, accounts, credentials, and access relationships across connected systems, including those outside the identity provider.
- Unified identity record: resolves the scattered accounts belonging to one person or one workload into a single current record, which turns a per-system finding list into a surface measurement.
- Graph view: maps identities, accounts, groups, applications, permissions, and access signals in one view, so relationship chains appear as paths instead of unrelated grants. It surfaces high-risk access, offboarding gaps, dormant accounts, and over-privileged users as working lists.
- AI Inventory and Task-Scoped Tokens: record which agents operate in the environment and who owns them, then scope an agent's permissions to the job in front of it rather than to a permanent role. Governed access does not have to accumulate into standing access between tasks.
- Secure Split Key (SSK): splits token-signing authority between NewCore's cloud and your own environment. Neither side can sign alone. A compromise of NewCore's cloud alone cannot forge a token, which removes the single signing key as a standalone point of compromise.
NewCore complements an existing identity provider and governance stack, connecting identity data across both as a shared discovery layer. The architectural case for that position is set out in building a secure core for your identity. Surface reduction begins as a discovery problem across the whole identity estate and only then becomes a control problem. Everything else is downstream of the count.
Agents are joining the workforce faster than any lifecycle can track them. Count them before you try to govern them. Request a Demo →
Frequently Asked Questions
How do you measure the identity attack surface for a board report?
Report paths instead of findings. The most legible measures are the number of identities that can reach each crown-jewel system, the share of privileged access that is standing rather than time-bound, and the share of identities with a named owner. All three move in a direction a non-specialist can read, and none of them rewards deleting empty accounts.
Is this the same as attack surface management?
They share a name and a logic, and they cover different assets. External attack surface management enumerates internet-facing systems and their exposures. The identity version enumerates who can reach what once inside. Many organizations now run both, and the identity side is usually the less mature of the two.
How does this relate to identity security posture management?
The distinction is mostly one of emphasis. Identity security posture management (ISPM) is the tooling category that measures standing weakness, and surface reduction is the program that acts on the result. Their overlap with threat detection is worth stating too: detection finds abuse in progress, posture and surface work reduce what that abuse is worth, and neither substitutes for the other.
Which identities should be reduced first?
Those with the shortest path to something that matters, which is often not the accounts that look most privileged on paper. A service account with write access to a build pipeline is frequently a shorter path to production than a domain administrator account that is watched closely and used rarely. Rank by reachability, not by title.
Can access reviews solve this on their own?
Not on their own, for a structural reason rather than a quality one. A review certifies the entitlements presented to the reviewer, and those entitlements come from the systems the governance product enumerates. A significant part of the surface may sit outside that enumeration, so a well-executed review can leave material exposure untouched and still produce a clean report.
