Enrollment, often called onboarding, establishes a digital relationship: an account is created, an identifier is assigned or selected, credentials are initialized, and attributes are recorded. It is a co-creation process because the system and the enrollee exchange the information needed to recognize one another later. The result is not merely an account; it is a relationship anchored by an identifier, protected by authentication, and shaped by context. section 3.3.1 section 3.4.1
A weak enrollment process can undermine strong authentication. Enrollment binds an account to attributes and authentication credentials, so later access decisions depend on whether those bindings and records are accurate. It also begins the identity relationship life cycle, which continues through propagation, use, update, and termination. section 3.10 section 3.4
Employee onboarding
Before Alice starts work, HR creates a record with her name, start date, department, manager, and location. The identity system creates her account, assigns an employee identifier, and initializes credentials. Alice registers a passkey, adds an account-recovery method, and accepts security policies. These details let the organization recognize her later and supply context for authentication and authorization. section 3.4
Enrollment decisions establish both identity confidence and the boundaries of the resulting relationship:
- Choose discovery and initiation. Self-service enrollment commonly starts when a person finds a service and selects Create Account; administrative enrollment is initiated and managed by a system or administrator. Device discovery may be governed by a protocol such as Bluetooth. section 3.3.1 section 3.4.1
- Create or assign an identifier and establish credentials. Administrative processes may deliver initial credentials out of band and require a user to change them at first sign-in; certificates generally do not require that change. section 3.4.1
- Collect and verify relevant attributes. Email addresses and mobile numbers may receive automated proofing, while certificates or biometrics can be recorded as authentication factors. Systems commonly assign initial roles and useful defaults. section 3.4.5
- Set a proofing level that matches risk and regulatory requirements. Proofing verifies the entity during enrollment; higher required confidence calls for more rigorous proofing. section 3.4.2
- Record relationship context, not just identity. Employment status, sponsor, department, location, organizational affiliation, and expiration dates can define what access is appropriate and for how long. section 3.4 section 3.4.3
Table 3.1 Summary of NIST Identity Assurance Levels (IAL), which define the strength of identity proofing during enrollment based on the required confidence in the claimed identity
| IAL Level |
Description |
Enrollment process example |
|---|---|---|
| IAL1 (low) |
Self-asserted identity; no formal identity proofing |
Signing up for an email account or a social media profile |
| IAL2 (moderate) |
Identity verified using trusted documents (e.g., driver’s license); verification may be remote |
Opening an online bank account with ID and selfie verification |
| IAL3 (high) |
In-person verification with biometrics or cryptographic binding to the identity |
Getting a passport, security clearance, or high-assurance enterprise login |
Compare NIST identity assurance levels to select proofing rigor: IAL1 accepts a self-asserted identity, IAL2 verifies trusted documents, and IAL3 uses in-person biometrics or cryptographic binding. section 3.4.2
Contractor versus employee
A contractor can receive an account and strong authentication through the same identity system as an employee, yet remain a different kind of relationship. A contractor record can identify the person as a contractor, name a sponsoring manager, and set a 90-day expiration. Authentication establishes confidence that the requester is the enrolled person; enrollment context tells access control what that relationship permits. section 3.4.3
Enrollment connects authentication to authorization. Authentication later verifies that an entity matches the account and credentials established at enrollment. Authorization can then use the recorded relationship context to decide what that authenticated entity may do. This distinction prevents strong sign-in from being mistaken for entitlement: a proofed contractor is still not an employee, and an authenticated individual acting for an organization needs delegation rights established through the relationship. section 3.10 section 3.4.3
Operationally, enrollment is a governance boundary. Proofing is often governed by organizational processes and can be vulnerable to human error, even where those processes are trusted internally. Risk tolerance and regulation may therefore require different enrollment journeys: financial services may use Know Your Customer requirements aligned to IAL2, while a social-media profile may use IAL1. Clear, durable enrollment records support controlled, explainable access as relationships change. section 3.4.2 section 19.4
