Identity is the complex and changing set of features, loyalties, values, roles, and self-descriptions that help define a person or group. In this article, it is treated as something broader than any single record, because identity can shift across time, context, and social setting.
What identity means in security and governance
Identity is not a single attribute or record. In security and governance, it is the stable enough story an organisation uses to recognise, distinguish, and relate a person or entity across changing contexts, roles, and claims.
That broad framing matters because many security problems begin when identity is treated as static, singular, or purely administrative. In practice, the same person can hold multiple roles, and the same entity can be represented differently across systems, communities, or time.
Identity as a moving boundary, not a fixed label
Identity is best understood as a boundary concept. It groups attributes, affiliations, and self-description into something that can be recognised, but it also changes as context changes, which makes identity partly social and partly operational.
For practitioners, that means identity always has a “who are we talking about?” problem. The answer may depend on context, consent, audience, timing, or purpose, which is why identity claims often need interpretation rather than simple lookup.
This is one reason identity can be broader than account data, profile fields, or a single credential. Systems may store identifiers, but real identity is usually assembled from many signals, relationships, and assumptions.
How identity differs from credentials and access
Identity is often confused with login, account, or authentication material, but those are supporting mechanisms rather than the concept itself. A password, token, or certificate may help establish identity, yet none of them fully defines it.
That distinction is important in cybersecurity because access decisions depend on more than proof of presence. They also depend on role, authority, context, and trust, which is why identity should be separated from the mechanisms that validate or use it.
For a practitioner view of how this matters in machine and service contexts, the broader identity lifecycle and control patterns are well illustrated in Ultimate Guide to NHIs.
Why identity is useful as a governance concept
Identity becomes valuable when organisations need to decide who counts as whom across systems, records, permissions, and responsibilities. That is why identity sits at the centre of trust, accountability, and many forms of policy enforcement.
In practice, identity also helps explain disputes and drift. A person’s identity can be consistent enough for recognition while still changing in values, affiliation, or function, which means identity governance must handle both continuity and change.
Modern identity systems are increasingly shaped by digital trust standards and authentication models. The OpenID Connect Core 1.0 specification shows how identity assertions are layered for authentication, while NIST SP 800-63 Digital Identity Guidelines frames assurance, proofing, and authenticator strength.
Identity and context across people, groups, and systems
Identity is not only personal. Groups, organisations, and other entities can also carry identity-like characteristics when they are recognised as coherent actors with shared roles, obligations, or representation.
That broader lens helps explain why identity questions appear in privacy, access control, organisational governance, and digital trust. The practical challenge is often not whether identity exists, but which version of it should be used for the decision at hand.
For a systems-level view of how identity is represented and enforced in technical environments, SPIFFE workload identity specification is a useful adjacent reference, and NIST SP 800-53 Rev 5 Security and Privacy Controls includes controls for identification, authentication, and access enforcement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines identity proofing and authentication assurance for digital identity. |
| Recommendation — Apply NIST 800-63 to set assurance levels for identity proofing and authentication. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Identity becomes operationally relevant where organisations must authenticate users. |
| IA-5 — Authenticator Management | Identity depends on lifecycle handling of authenticators and related secrets. | |
| Recommendation — Use IA-2 to require strong authentication for organisational identities. Use IA-5 to manage authenticators across issuance, rotation, and revocation. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity governance is explicitly covered as an organisational control area. |
| A.5.17 — Authentication information | Identity is linked to the handling of authentication information and proof material. | |
| A.5.18 — Access rights | Identity governs how access rights are allocated and reviewed. | |
| Recommendation — Implement A.5.16 to manage identity records, ownership, and lifecycle. Apply A.5.17 to protect and control authentication information. Use A.5.18 to assign, review, and revoke access rights consistently. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Identity is central to how CSF protects access and trust. |
| GV.OC-01 — Organizational mission is understood and informs cybersecurity risk management | Identity as a governance concept depends on organisational purpose and context. | |
| Recommendation — Use PR.AA-01 to manage identity issuance, verification, revocation, and auditability. Align identity governance to mission, roles, and accountability through GV.OC-01. | ||
| OWASP ASVS | V6 — Authentication | Identity claims in applications are established through authentication controls. |
| V8 — Authorization | Identity becomes actionable when it is mapped to access decisions. | |
| Recommendation — Apply V6 to verify authentication strength and identity assurance in applications. Use V8 to verify that identity-backed permissions enforce least privilege. | ||
