The Zero Trust domain that governs how identities are verified, authenticated, and authorised across systems. It focuses on continuous identity assurance, strong access controls, and authentication methods that can withstand phishing and credential abuse. In federal Zero Trust programmes, it is a required foundation for broader access decisions.
Expanded Definition
The identity pillar is the Zero Trust domain that decides whether a user, service, device, or workload is who it claims to be before access is granted. It is narrower than general access management because it emphasises identity assurance, authentication strength, and the conditions under which trust is continuously re-evaluated.
In practice, the pillar covers initial verification, session-based rechecks, authentication policy, and the handoff to authorisation decisions. It is not the same as the data pillar, device pillar, or network perimeter, although it often depends on signals from them. In federal Zero Trust guidance, the identity function is foundational because weak identity proofing or weak authentication undermines every later access decision.
Definitions vary across vendors on where identity ends and policy enforcement begins, but the operational boundary is usually clear: if the control determines who or what is trusted, it belongs here. For machine access and service identities, the same logic applies to keys, tokens, certificates, and delegated credentials.
Examples and Use Cases
The identity pillar shows up anywhere access must be granted with evidence instead of assumption. It is most visible in environments that replace static trust with stronger, context-aware verification.
- Employees authenticate through phishing-resistant methods before reaching internal applications.
- Service accounts use short-lived credentials so access can be tied to a known workload or job.
- Privileged administrators step up to stronger authentication before sensitive actions are allowed.
- API gateways or policy engines re-check identity claims when a session changes risk or location.
- Machine-to-machine connections use certificates or token-based trust rather than shared passwords.
This pillar often creates a tradeoff between user friction and assurance. Stronger controls can slow access slightly, but they reduce the chance that a stolen password, reused token, or spoofed account becomes a trusted session.
For NHI-heavy environments, NHIMG’s Ultimate Guide to NHIs is useful because it connects identity governance to lifecycle issues such as rotation, visibility, and offboarding.
Security Implications
When the identity pillar is weak, Zero Trust degrades into a policy layer sitting on top of untrusted credentials. That failure often shows up as excessive session trust, weak reauthentication, or approval flows that assume the login event was enough to establish legitimacy.
Mismanagement can produce broad blast radius: one compromised account may reach many systems if identity checks are shallow, infrequent, or inconsistent across applications. The same weakness also affects machine identities, where long-lived secrets or over-privileged service accounts can persist unnoticed and remain valid far beyond the original risk window.
NHIMG’s research shows why this matters operationally: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In practice, that means identity failure is rarely isolated to one login event; it often becomes a trust problem that spreads across applications, automation, and partner integrations.
A common practitioner observation is that identity weaknesses are often hidden by successful logins. If monitoring only records acceptance or denial, it can miss the more important issue: whether the identity was ever appropriately bound to the action being performed.
Domain and Governance Relevance
The identity pillar matters because it is the control plane for trust decisions. Without reliable identity assurance, authorisation policies lose meaning, and the organisation cannot confidently distinguish legitimate access from borrowed, spoofed, or compromised access.
In NHI governance, the meaning expands beyond people. Service identities, workload identities, API keys, certificates, and automation accounts must be inventoried, authenticated, scoped, and retired with the same seriousness as human accounts. That changes governance from a login-centric model to a lifecycle model that includes issuance, rotation, delegation, revocation, and visibility.
For teams implementing Zero Trust, this pillar is often where policy intent becomes measurable: stronger authentication, reduced standing trust, and clearer ownership of who or what is allowed to act. NHIMG’s Top 10 NHI Issues is a useful companion when the question is how identity governance changes once machine actors become first-class participants.
Where identity is treated as a one-time check, the organisation usually overestimates its security posture. Where it is treated as an ongoing trust relationship, access decisions become much harder to spoof or abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), CIS Controls v8, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 3.0 — Zero Trust Identity Pillar | Defines identity as the trust basis for access decisions in Zero Trust. |
| Recommendation — Treat identity as the primary trust signal and require continuous verification before access. | ||
| CIS Controls v8 | 6 — Access Control Management | Covers account and access governance needed to enforce identity-based access. |
| Recommendation — Enforce least privilege and remove unnecessary access paths tied to identities. | ||
| NIST SP 800-63 | 3 — Digital Identity Guidelines | Covers identity proofing, authentication, and federation assurance for identities. |
| Recommendation — Apply stronger authentication and assurance levels to match the sensitivity of access. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Machine and workload identities rely on keys, tokens, and certificates as their credentials. |
| Recommendation — Inventory, rotate, and revoke machine credentials before they become standing trust. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Maps identity assurance and access control governance to Zero Trust identity decisions. |
| Recommendation — Align identity checks with access policy and verify that authentication supports each decision. | ||
