What it means
A digital identity is the representation a system uses to distinguish an entity. That entity may be a person, a device, or software performing work. Its account or record can hold identifiers, attributes, credentials, ownership, and lifecycle information. Those details support later authentication and access decisions.
An account name is not proof of the human who performed an action. A credential may be shared or stolen, and automated workloads can act without a person present. Identity proofing establishes a claimed real-world identity when the use case requires it; authentication checks control of an authenticator later. Keep these stages distinct when investigating or designing access.
The idea at a glance / Identity
One subject. Two service accounts.
A maintained identity record links Kael Cho to two different service accounts. Those links do not authenticate a login or grant a task.
Fictional directory U042 at id.chronos.orbital represents employee E104, Kael Cho. PeopleOps has established this link; Chronos Hub FL-17 and Testbench TP-63 both refer to U042.
READ THE PICTURE
Read the mapping
U042 represents Kael Cho and links to Chronos Hub FL-17 and Testbench TP-63. PeopleOps and IT maintain these records. A later login must verify an authenticator for its account, and a requested task still needs its own permission check.
Keep in mindThis is an assumed account mapping, not proof of who is at a device, a grant of permission, or a demonstration of identity proofing. Identifiers are local to the named systems.
Read the complete example
- Read the mapping. U042 represents Kael Cho and links to Chronos Hub FL-17 and Testbench TP-63. PeopleOps and IT maintain these records. A later login must verify an authenticator for its account, and a requested task still needs its own permission check. This fictional directory record U042 represents employee E104, Kael Cho. PeopleOps has already established the subject-to-record association; the picture does not carry out or establish identity proofing. Chronos Hub account FL-17 and Testbench account TP-63 each contain a reference to U042. These are different account identifiers in different services, not additional people. The drawn connectors represent maintained associations, not exchanged messages. Display names can change or collide; the local record reference is used to maintain the links. PeopleOps owns the employment relationship and IT maintains the service accounts, reviewing role changes and account closure. The mapping does not show authenticator evidence, decide a resource permission, establish that the current requester is Kael, or prove that every linked account was disabled when employment ended. Authentication, authorization, and lifecycle verification require their own evidence. People, devices, and workloads can be identity subjects; this example covers one employee only.
This is an assumed account mapping, not proof of who is at a device, a grant of permission, or a demonstration of identity proofing. Identifiers are local to the named systems.
Diagram references: NIST SP 800-63A-4 - Subscriber Accounts · NIST SP 800-63B-4 - Authentication
AN ILLUSTRATIVE SCENARIO
A hospital scheduling integration
A hospital creates a separate workload identity for software that transfers appointment availability between systems. The identity has a named technical owner, a documented purpose, and access only to the required scheduling data. It does not inherit a staff member's broad account simply because that person configured the integration. When the integration is retired, the owner removes its access and credentials. Logs can then distinguish the integration's actions from a scheduler's interactive work.
Put it to work
- Inventory the identities used by people, devices, and workloads, including their owners, purpose, authoritative source, and lifecycle status.
- Choose appropriate identity establishment and authentication methods; record how credentials bind to the intended entity without assuming usernames prove attribution.
- Connect account creation, changes, and removal to real events such as hiring, role changes, device retirement, or application decommissioning.
How to check your work
Choose an account and trace its owner, purpose, credential, and approved access. Confirm that a lifecycle change reaches every connected system and that activity can be attributed with stated limits.
Connect the ideas
- Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- IAM
The capability for creating identities, authenticating them, authorizing actions, and managing their lifecycle.
- Attestation
Evidence or a statement about a claimed device, workload, or control state that another party can evaluate against its requirements.