What is the difference between batch issuance and self-service provisioning for FIDO2 passkeys?

Batch issuance is an administrator-led process that preconfigures and distributes credentials in bulk, usually with defined policies, branding, and access settings. Self-service provisioning shifts part of enrollment to the end user, which can improve speed and reduce administrative effort. The right choice depends on how tightly the organisation needs to control identity proofing, policy enforcement, and device standardisation.

Why the distinction matters for passkey rollout

Batch issuance and self-service provisioning solve different operational problems, even though both end with a user holding a FIDO2 passkey. Batch issuance is best when the organisation wants tight control over who gets enrolled, which device profile is used, and what policy is attached from the start. Self-service provisioning is better when the goal is faster rollout and less help desk involvement, but it shifts more trust to the user journey and the proofing step that precedes enrollment.

That difference matters because the enrollment path shapes the assurance of the credential lifecycle. If the first registration step is weak, the passkey may be bound to the wrong person or a non-standard device, and later policy enforcement has to compensate for an avoidable trust gap. The relevant controls are often less about the cryptography of FIDO2 itself and more about identity proofing, device eligibility, and recovery design. Current guidance on digital identity, including the NIST SP 800-63 Digital Identity Guidelines, is useful here because it separates identity assurance from authenticator properties.

For teams managing large fleets or regulated users, the practical question is whether enrollment should be centrally curated or delegated into a user-led flow. In practice, many organisations discover the weakness in their provisioning model only after users have already enrolled at scale and exceptions have become expensive to unwind.

How batch issuance and self-service provisioning work in practice

Batch issuance usually begins with an administrator or identity team pre-creating enrollment records, attaching policy, and distributing activation instructions in bulk. That model works well when users are known in advance, devices are standardised, and the organisation wants to control the pace of adoption. It also supports stronger consistency in branding, support scripts, recovery procedures, and audit evidence. The trade-off is that it adds operational overhead and can become rigid when users change devices frequently or work across mixed environments.

Self-service provisioning, by contrast, lets the end user initiate registration through an approved portal or authentication flow. The user still has to satisfy the organisation’s proofing and eligibility rules, but the workflow is designed to reduce manual steps. That makes it attractive for distributed workforces and lower-friction onboarding. The risk is that convenience can tempt teams to relax the enrollment gate, which turns a smoother user experience into a weaker identity checkpoint.

In a strong implementation, the passkey decision is not treated as merely a frontend choice. It is tied to:

how the user’s identity is verified before registration,
whether the device meets minimum security and attestation requirements,
what recovery path exists if the passkey is lost or replaced, and
whether the organisation needs central control for audit, compliance, or privileged access.

For NHI-heavy environments, the same lifecycle logic appears in credential governance more broadly. NHIMG research on lifecycle discipline shows that unmanaged credentials create persistent exposure, and that lesson transfers directly to passkey provisioning: if issuance is easy but revocation, replacement, and visibility are weak, the rollout will look successful while the control plane remains fragile. The NHIMG Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant because it reinforces the importance of governed onboarding, rotation, and offboarding rather than one-time enrollment. These controls tend to break down when self-service is extended into high-assurance or privileged use cases without a stronger proofing and recovery design.

Where teams get the comparison wrong

Tighter batch control often increases administrative effort, requiring organisations to balance assurance against onboarding speed. The common mistake is to assume that self-service is always “modern” and batch issuance is always “legacy.” In reality, the right model depends on whether the enrollment step needs to establish a high-confidence identity binding or simply streamline access for a low-risk population.

Another edge case is device standardisation. If the organisation requires managed endpoints, hardware-backed keys, or specific attestation behaviour, batch issuance can support cleaner policy enforcement. If users bring varied personal devices, self-service may scale better but can produce more support cases and more uneven assurance. Best practice is evolving, and there is no universal standard for which approach is inherently better; the correct answer is driven by assurance needs, device diversity, and recovery maturity.

For privileged users, contractors, or regulated workflows, the decision often shifts toward batch issuance or a hybrid model because the organisation needs stronger oversight over enrollment conditions. For general workforce use, self-service can be efficient if the proofing step is robust and exceptions are tightly managed. The most useful test is whether the provisioning path can be audited end to end without depending on informal manual checks. If not, the convenience of self-service may be offset by weak accountability when something goes wrong.

Risk and Threat Considerations

The main risk is not the passkey itself but the trust boundary created during enrollment. If self-service provisioning weakens proofing or device eligibility checks, an attacker can exploit account recovery, weak identity verification, or social engineering to bind a valid passkey to the wrong identity.

Failure mechanism: The weakness materialises when the organisation treats user-led enrollment as equivalent to centrally assured issuance. Poor proofing, permissive recovery, or unmanaged device enrollment can let an unauthorised party register an authenticator that the system later trusts as legitimate.

Impact: The result can be persistent account compromise, failed auditability, and a recovery problem that is harder to unwind than a simple password reset because the authenticator is now part of the normal trust chain.

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, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	IAL — Identity Assurance Level	Passkey enrollment hinges on identity proofing strength before registration.
	AAL — Authenticator Assurance Level	FIDO2 passkeys are authenticator choices that must match assurance needs.
	AAL2 — Authenticator Assurance Level 2	Passkeys are commonly used to satisfy phishing-resistant MFA expectations.
Recommendation — Set the required assurance level before allowing passkey enrollment. Match the authenticator to the assurance level required by the use case. Use phishing-resistant authenticators where stronger login assurance is needed.
CIS Controls v8	5 — Account Management	Issuance and revocation of access hinge on controlled account lifecycle handling.
	6 — Access Control Management	Enrollment models differ in how tightly access eligibility and policy are enforced.
Recommendation — Centralise account provisioning and remove access promptly when it is no longer needed. Apply least-privilege access rules to enrollment and recovery workflows.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Passkey provisioning is fundamentally an identity and access governance decision.
	PR.DS — Data Security	Passkey setup depends on protecting credentials, recovery data, and enrollment records.
Recommendation — Align enrollment flows with identity assurance and authentication requirements. Protect enrollment artifacts and recovery data throughout the credential lifecycle.
NIST Zero Trust (SP 800-207)	SP 800-207 — Zero Trust Architecture	Enrollment choice affects how much implicit trust is granted during authentication setup.
Recommendation — Minimise implicit trust in enrollment and re-evaluate trust continuously.

Practitioner Guidance

What to prioritise: Treat the proofing step and the recovery path as the real control points, not the passkey registration screen. If those two pieces are weak, the choice between batch and self-service is mostly cosmetic.

Decision rule: Use batch issuance when the user population is tightly managed, device standards matter, or enrollment must be auditable at a high assurance level. Use self-service when speed and scale matter and the organisation can still enforce strong identity verification, device checks, and exception handling.

What to verify: Confirm that lost-device recovery, re-enrollment, and revocation are as well governed as initial issuance. A rollout is not mature until a removed user can no longer authenticate and a replaced device cannot silently inherit trust.

Practitioner takeaway: The governing question is not “which enrollment method is easier,” but “which method preserves the identity assurance the business actually needs after the first registration event.”