Category: Identity Lifecycle

Applicant

Simply put

In the general sense, an applicant is a person who applies or signs up for something, such as a job or a service. In identity systems specifically, an applicant is a person who is going through the process of proving their identity before they can be granted an account or credential.

Formal definition

In common usage, an applicant is simply an individual who expresses interest in or applies for something, for example a job applicant who completes an application form. In the IAM and digital-identity context, the term typically denotes the subject undergoing identity proofing and enrollment prior to becoming an enrolled subscriber or account holder; the provided evidence, however, only supports the general-language definition, and the identity-proofing usage aligns with digital-identity guidance rather than any source in this evidence packet. This term describes a lifecycle/enrollment role and does not by itself imply any authentication or authorization outcome; whether an applicant ultimately receives credentials or access depends on the enrollment, proofing, and provisioning processes applied.

Why it matters

The applicant role marks the entry point of the identity lifecycle, before any account, credential, or access exists. Getting this stage right is foundational: every downstream authentication and authorization decision inherits the assurance, or the weakness, of how well the applicant's claimed identity was established. If proofing is weak or skipped, an attacker can enroll as a legitimate subject and inherit trust that no runtime control can later fully undo, because the credential itself will validate correctly even though it was issued to the wrong person.

Distinguishing the applicant from the enrolled subscriber also matters for governance and accountability. An applicant has expressed interest or begun a process but has not yet been granted anything; conflating the two can lead to premature provisioning, orphaned records, or audit gaps around who was proofed, when, and to what level of confidence. Keeping the applicant a distinct lifecycle role clarifies that being an applicant carries no authentication or authorization outcome by itself, those depend entirely on the proofing, enrollment, and provisioning processes that follow.

In digital-identity practice, the applicant stage is where identity proofing standards and regulatory expectations apply. Because the outcome of this stage determines the identity assurance associated with the eventual account, treating the applicant as a deliberately scoped role helps organizations map their enrollment controls to the assurance levels their use cases require, rather than assuming trust that was never actually established.

Who it's relevant to

IAM Engineers and Enrollment System Designers

They implement the flows that move a person from applicant to enrolled subscriber, including evidence capture and the handoff to provisioning. Treating the applicant as a distinct, credential-less role helps prevent premature account creation and keeps enrollment logic cleanly separated from runtime authentication and authorization.

Identity Governance and Administration Leads

The applicant stage sits at the front of the identity lifecycle that IGA teams oversee. Distinguishing applicants from active subscribers supports accurate record-keeping, avoids orphaned or duplicate identities, and clarifies accountability for who was proofed and under what conditions.

Compliance Officers and Auditors

Because the assurance associated with an eventual account is established at the applicant stage, auditors need to verify that proofing and enrollment controls match the required assurance level. A clearly scoped applicant role makes it easier to demonstrate where identity was established and where trust decisions were actually made.

Security Architects

Architects rely on the applicant-to-subscriber distinction when modeling trust boundaries. Weak proofing at the applicant stage propagates into every later authentication and authorization decision, so architects treat enrollment assurance as a foundational input rather than an afterthought.

Inside Applicant

Applicant (identity proofing role)

In NIST SP 800-63 terminology, the applicant is the subject who is undergoing identity proofing and enrollment before becoming a subscriber. The term denotes a specific stage in the identity lifecycle rather than an authenticated or authorized principal.

Position within the enrollment flow

The applicant status precedes subscriber status. Per SP 800-63A, the applicant submits identity evidence to a Credential Service Provider (CSP) or Registration Authority; upon successful proofing and enrollment, the applicant transitions to a subscriber and may be bound to authenticators. This is part of identity establishment, not runtime authentication or authorization.

Identity evidence and proofing

The applicant provides identity evidence (such as documents or attributes) that the CSP validates and verifies during identity proofing. In SP 800-63A this activity is associated with Identity Assurance Levels (IALs), which describe the rigor of the proofing process. The specific evidence types and validation methods depend on the target IAL and deployment context.

Relationship to the subscriber and CSP

The applicant interacts with the CSP (and, where used, a Registration Authority) that performs proofing. Once enrollment completes, the resulting subscriber account and any bound authenticators are what later support authentication events. The applicant role itself is an IGA/identity-establishment concept, distinct from runtime enforcement components such as a PDP or PEP.

Common questions

Answers to the questions practitioners most commonly ask about Applicant.

Is an applicant just any user trying to log in or access a system?

No. In the context of NIST SP 800-63 identity proofing, an applicant is specifically the subject undergoing identity proofing before becoming a subscriber. It is a lifecycle-stage term tied to enrollment and identity proofing, not a general term for any principal attempting authentication or authorization at runtime. A person authenticating to an established account is acting as a subscriber (or claimant during an authentication event), not an applicant.

Does becoming an applicant mean the person already has a verified identity or credential?

No. An applicant is the subject at the identity-proofing stage, before the identity has been resolved, validated, and verified to the degree required and before enrollment completes. The applicant has not yet been bound to authenticators or issued credentials as a subscriber. Identity proofing (establishing who the subject is) is distinct from later authentication (verifying a returning subject) and from any authorization decisions.

At what point in the identity lifecycle does an applicant become a subscriber?

Under the NIST SP 800-63 model, the applicant transitions to subscriber upon successful completion of identity proofing and enrollment, at which point the subject is enrolled and, depending on the deployment, bound to one or more authenticators. The exact steps and evidence required vary by the identity assurance level and the specific profile in use.

How should the applicant stage be represented in an IGA provisioning workflow?

In most deployments the applicant stage maps to a pre-account or candidate state that precedes account provisioning. Governance controls such as identity proofing checks and evidence capture typically occur here, before any entitlements are assigned. Keeping this stage distinct from the active subscriber state helps separate enrollment-time governance from runtime access enforcement, and depending on configuration it may be modeled as a separate lifecycle status rather than a provisioned directory entry.

What data is typically collected about an applicant, and how does it differ from subscriber data?

During the applicant stage, identity evidence and attributes used for identity proofing are typically collected and evaluated. This differs from subscriber data, which centers on the enrolled identity record and any bound authenticators used for subsequent authentication. Retention and handling of proofing evidence often carry different requirements from operational account data, and specifics depend on the applicable policy, assurance level, and jurisdiction.

Should applicant records be stored in the same directory as active subscriber accounts?

This depends on the deployment. Some implementations stage applicant data in a separate proofing or onboarding store and only create a directory entry (for example an LDAP entry or a provisioned account via SCIM) once the subject becomes a subscriber, while others maintain a status attribute on a single record. Separating the two can reduce the risk of unproofed identities being treated as authenticatable accounts, but the appropriate approach varies by vendor and architecture.

Common misconceptions

There is no IAM-specific definition of applicant.

NIST SP 800-63 (a current digital-identity guideline widely used in the IAM industry) explicitly defines applicant as the subject undergoing identity proofing before becoming a subscriber. The term has a precise, standards-based meaning within the identity lifecycle.

An applicant is an authenticated user who can access resources.

The applicant precedes subscriber status and is engaged in identity proofing and enrollment, which is an identity-establishment step. Authentication (verifying a returning subscriber) and authorization (determining what a principal may do) occur later and involve separate mechanisms; being an applicant confers no access.

Applicant and subscriber are interchangeable terms.

They denote different lifecycle stages. In SP 800-63 terminology the applicant becomes a subscriber only after successful proofing and enrollment; the subscriber is the party subsequently bound to authenticators and recognized in authentication events.

Best practices

Use the term applicant strictly for the identity-proofing and enrollment stage, and switch to subscriber once proofing and enrollment complete, to keep lifecycle stages unambiguous in policy and documentation.

Align applicant proofing rigor with the target Identity Assurance Level (IAL) defined in SP 800-63A, and document which evidence types and validation steps apply at your chosen level rather than assuming a one-size-fits-all process.

Keep applicant/proofing activities (identity establishment, an IGA concern) separate from runtime enforcement components such as PDP, PEP, and token validation in both architecture and terminology.

Do not treat applicant status as an authentication or authorization state; ensure no access decisions are granted based on the applicant role alone.

Record the transition from applicant to subscriber as an explicit, auditable event so that later access reviews and certifications can trace how an identity was established.

Where a Registration Authority or CSP handles proofing, clearly define its responsibilities and its boundary with downstream authentication systems so the applicant handoff to subscriber is traceable and reviewable.