Zero trust identity is the application of zero trust principles to accounts, credentials, sessions, and entitlements. No request is authorized solely on the strength of a decision made earlier, and every request is evaluated against current context before it is allowed. Two things have to move together for that to hold. Authentication gets stronger, and standing access gets smaller.
Most programs do the first and stall on the second. A security team can roll out phishing-resistant authentication to the whole workforce and retire passwords entirely. The same estate can still run a service account whose key was issued for a 2022 migration. It carries write access to a production storage tier. Nothing about that account was trusted implicitly. Nobody looked at it.
That gap is where the work sits. An identity estate covers employees, contractors, service accounts, automations, and AI agents. The human identities usually arrive with an owner, a start date, and an end event. Most machine and agent identities do not.
What Is Zero Trust Identity?
Zero trust identity applies the doctrine of never trust, always verify to the identity layer specifically. Network-centric zero trust asks whether traffic should reach a segment. Identity-centric zero trust asks whether this subject, in this state, on this device, should perform this operation on this resource, right now.
NIST's glossary defines zero trust as a collection of concepts designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in the face of a network viewed as compromised. Per-request is the operative word. It rules out the design most estates actually run, where one successful authentication issues authority that stands until something revokes it.
The CISA Zero Trust Maturity Model version 2.0 turns that into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Visibility and Analytics, Automation and Orchestration, and Governance run across all five. CISA's definition of identity includes non-person entities, placing service accounts, workloads, API clients, and automations inside the identity pillar rather than beside it.
CISA scores each identity function across four stages. Two columns are enough to see the shape of the argument:
| Identity function | Traditional | Optimal |
|---|---|---|
| Authentication | Passwords or MFA, with access remaining static after authentication | Identity validated continuously with phishing-resistant MFA, not only when access is first granted |
| Identity stores | Self-managed and on-premises only | Stores integrated across partners and environments |
| Risk assessments | Limited determinations of identity risk | Identity risk determined in real time from continuous analysis and dynamic rules |
| Access management | Permanent access with periodic review, privileged and unprivileged alike | Automated just-in-time and just-enough access, tailored to individual actions and resources |
Across the four rows, the optimal column describes broader identity visibility, continuous risk assessment, and shorter-lived authority rather than stronger credentials alone. That is the part most maturity assessments skip, because it is the part that requires taking something away.
Why Identity Is the New Security Perimeter
Identity earned the perimeter label by elimination. When applications run in SaaS tenants and cloud control planes, no network position has to be crossed first. The gate is an authorization decision, and what passes through it is a token.
MITRE ATT&CK catalogs this as Use Alternate Authentication Material (T1550), covering application access tokens, Kerberos tickets, password hashes, and web session cookies across identity providers, SaaS, IaaS, and other platforms. Each lets a system recognize an authenticated identity without requiring the original factors again. If stolen, that material can carry the attacker's authority forward. MITRE places T1550 under lateral movement, putting token theft in the middle of an intrusion rather than at its front door.
That placement is the part the perimeter slogan gets wrong. Identity is not only where intrusions start. It is where they become valuable. An attacker who lands on an unpatched edge appliance still has to acquire something that authorizes reaching data. The credentials that work best already hold permissions to whatever is worth taking. Making the first login harder is worth doing. Making a compromised identity worth less is the part zero trust is about.
Core Principles of Zero Trust Identity Security
Zero trust identity and access management rests on five principles. Each one is stated here with the standing weakness it removes, because a principle with no failure mode attached is a slogan.
Verify explicitly, on current signals. Every access decision consults identity, device posture, session risk, and resource sensitivity at the moment of the request. The weakness removed is the inherited decision, where a session issued under one set of conditions keeps authorizing actions under another. Device trust signals belong in that evaluation, not only in the initial login.
Grant least privilege, and time-bound it. Permissions match the task and they expire. The weakness removed is accumulation. Roles granted for a project, a migration, and an incident can outlive all three, and the sum of those survivals becomes part of what an attacker inherits.
Assume breach at the identity layer. Design as though some credential in the estate is already under someone else's control. The weakness removed is the single-account blast radius, where one compromised login reaches everything its owner's team ever needed.
Keep verifying after the session opens. Continuous verification means re-evaluating an established session when context changes, and being willing to end it. CISA's optimal state for authentication says the same thing in plainer language: validate identity continuously, not only when access is first granted. The weakness removed is session persistence past the conditions that justified it.
Cover every identity type. Human, machine, service account, automation, and AI agent identities all fall inside the policy. The weakness removed is the exemption, which in most estates is not a documented exception but an omission nobody wrote down.
Eliminating Identity-Based Attack Paths
An attack path is a sequence of individually permitted steps that ends somewhere it should not. Zero trust identity security is measured by how many of those sequences survive, which is a different number from how many accounts have MFA turned on.
Take one. A contractor account in Entra ID belongs to a group mapped to an AWS IAM role during a 2023 data migration. The engagement ended and the account was disabled, but the group-to-role mapping remained. Any identity later added to that group inherits the path. No single grant looks obviously wrong in isolation. The risk appears when the relationships are read together.
Finding paths like that means enumerating relationships rather than accounts: which identities can reach this resource, through which grants, and which of those grants is justified by something happening now. Authentication strength appears nowhere in that analysis.
Decision rule: treat permissions unused during a meaningful window as candidates for removal. Check for seasonal or emergency dependencies, then remove what nobody needs. Where access is active but broadly scoped, replace it with just-in-time access that expires with the grant. Monitoring an unnecessary entitlement is the most expensive way to keep it.
Teams already running a posture program will recognize the overlap. Measuring standing posture weakness and eliminating attack paths are closely related activities, and running them as isolated projects duplicates the identity and entitlement mapping both depend on.
Protecting Human and AI Agent Identities With Zero Trust
Zero trust identity management gets harder when the subject is not a person, and the difficulty is operational rather than conceptual. The principles carry over intact. The assumptions underneath them do not.
Human identity management starts with a joiner event, a manager, a review cycle, and a leaver event. An AI agent can be created on a Tuesday afternoon, granted an OAuth scope against a production API, and left running with no owner, expiry, or event that ends it. Least privilege and continuous verification both depend on knowing that agent exists. Neither comes for free.
Three adjustments make the principles operable on the non-human side:
- Ownership is recorded at creation time. A service account or agent with no named human or team owner has nobody who can reliably justify its access. It may still enter a review, but without an accountable reviewer its access tends to accumulate.
- Credentials are short-lived and scoped to the task. A token bound to one operation, audience, and short time window limits where it can be replayed and how long stolen access remains useful. On the non-human side, this is the control with the best return for the effort.
- Policy is evaluated on every request. Agents chain actions across systems in sequences their authors never enumerated. The moment of the call is the clearest point at which the requested action, target, and context are visible together. That is the argument behind an adaptive access policy for people, running at machine speed.
Best Practices for Building a Zero Trust Identity Strategy
Zero trust identity governance succeeds or fails on sequencing. These six steps are ordered deliberately, because several of them do nothing when performed early.
- 1.Enumerate before you enforce. Build the identity inventory across the systems that issue credentials, including those outside the identity provider. Every later step depends on this list, and every gap becomes a governance blind spot.
- 2.Assign an owner to every identity, non-human ones included. An identity with no owner has nobody who can justify its access, and unjustifiable access survives because nobody volunteers to be the person who broke production.
- 3.Map paths, not permissions. Score the estate on which identities can reach which sensitive resources through any chain of grants. This is the number that says whether the program is working.
- 4.Raise assurance where the path is shortest. Apply phishing-resistant methods first to the identities with the fewest steps between them and something that matters, rather than rolling out by department or by convenience.
- 5.Convert standing access to time-bound access. Start with roles that are broadly scoped and rarely used, where the ratio of risk removed to disruption caused is highest.
- 6.Re-evaluate on a cadence your risk appetite and control framework set. Review frequency follows the sensitivity of the access and the rate at which the estate changes. Those vary enough between organizations that a fixed interval is guidance dressed as a requirement.
Decision rule: if a proposed zero trust initiative changes neither the number of identities that can reach a sensitive resource nor the length of time they can reach it, it is an authentication project. That may still be worth funding. It should not be counted as zero trust progress.
One pressure on this sequence is arriving on its own schedule. Agent populations grow faster than review cycles, and a program built around periodic attestation will meet identities that were created and retired between two reviews. The ordering above holds. The interval between steps is what has to compress.
How NewCore Enables Identity-Centric Zero Trust Security
A program that verifies every human request but never enumerates its service accounts and agents has moved the perimeter, not removed it. NewCore was built around that gap. A policy covering only the human workforce is not a zero trust policy. It is a well-authenticated subset.
- Security-aware policies: human and AI identities share one policy engine and one strength model. Unconfigured access defaults to a high-strength baseline, and overlapping policies resolve toward the stronger authenticator instead of the weaker fallback. An agent cannot inherit a softer path than the person doing the same work.
- JIT access that expires with the grant: elevation requires verified authenticator strength and ends when the grant ends. Access opened for an incident does not become a permission held next quarter.
- Agentic SSO and Task-Scoped Tokens: permissions are scoped to the job in front of the agent, not the agent's permanent role. An agent cannot accumulate standing access beyond its current task.
- AI Inventory: records which agents operate in the environment, what they connect to, and who owns them. That is the enumeration step every principle above assumes and most estates lack.
- Identity Discovery: continuously indexes identities, accounts, credentials, and access relationships across connected HRIS, directories, IdPs, IGA, PAM, cloud, SaaS, and AI platforms, resolving scattered accounts into one current record. Least privilege then applies to a subject rather than to one of its several accounts.
NewCore runs standalone or alongside an existing identity provider and policy engine, so governing the agentic side does not require replacing the identity stack already serving the human workforce. Governance of the agentic side moves through the same controls as the human side, from one converged identity core. Zero trust is a scope claim before it is an architecture claim.
Welcome to the agentic era. Verify every identity in it, not only the ones with a manager. Request a Demo →
Frequently Asked Questions
Is zero trust identity a product you can buy?
No. It is a set of architectural decisions that several products help implement. Identity providers, privileged access tools, governance platforms, and policy engines each cover part of it. The parts organizations struggle with most, ownership and enumeration of non-human identities, are frequently not covered by any of them out of the box.
Does zero trust mean getting rid of VPNs and network segmentation?
Not necessarily, and treating it that way causes problems. Zero trust reduces reliance on network position as a proxy for trust. Segmentation still limits blast radius, particularly for systems that cannot participate in modern authentication. What changes is that sitting inside a network no longer constitutes authorization on its own.
How long does a zero trust identity program take?
Long enough that a fixed answer would be dishonest. The dominant variables are how many systems issue credentials outside the identity provider, how much of the estate supports modern authentication, and how much standing access exists at the start. Teams that begin with enumeration usually get a defensible estimate during the first phase, which is one argument for sequencing it first.
Do compliance frameworks require zero trust?
Some government directives and control frameworks reference zero trust architecture explicitly, and CISA's maturity model exists to support one of them. Many other frameworks require controls that a zero trust approach satisfies without naming it. Whether it applies to you depends on your specific obligations and the framework you map to, which is a question for your compliance function.
Where do most zero trust identity programs stall?
At the point where enforcement would break something. Enumeration and policy design are tractable. Removing an entitlement that a production process quietly depends on is where the pace drops. The teams that get through it tend to be the ones that built the dependency picture during enumeration rather than during enforcement.
