Per-device provisioning ties a security key or authenticator to a single physical unit, while per-user provisioning gives each person a managed entitlement to use strong authentication across approved devices or replacements. Per-user models usually improve flexibility, simplify lifecycle handling, and support predictable spend. They are especially useful when organisations need scalable distribution, replacement, and user-level management across a large workforce.
How the Two Provisioning Models Actually Split Responsibility
The practical difference is where the control “lives.” Per-device provisioning binds the authenticator to a single endpoint, so the device becomes the unit of trust. Per-user provisioning binds the entitlement to the person, so the user remains the stable identity across approved endpoints. That distinction changes how you handle replacement, loss, onboarding, and day-to-day administration.
In enterprise operations, the key trade-off is rigidity versus portability. Device-bound provisioning can be simpler when the endpoint itself is tightly managed and highly controlled, but it becomes awkward when users move between laptops, phones, or shared environments. User-bound provisioning is usually better when the organisation wants consistent access across a fleet of approved devices without reissuing the core entitlement each time the hardware changes.
For teams that need lifecycle clarity, the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is useful for understanding how provisioning, rotation, and offboarding are handled as lifecycle events rather than one-off setup tasks. The same lifecycle thinking applies here, even when the object is a human authenticator instead of a machine credential.
- Per-device provisioning: easier to tie access to one known hardware unit, harder to support replacement at scale.
- Per-user provisioning: easier to support device turnover and user mobility, but it depends on stronger entitlement governance.
- Per-user models usually fit environments with large workforces, frequent endpoint churn, or bring-your-own-device patterns.
Why the Choice Changes Operations, Cost, and Control
Per-device models tend to push effort into endpoint handling. Every replacement, reset, or hardware refresh can trigger a provisioning event, and that makes logistics more expensive as the fleet grows. Per-user models shift effort into identity administration and policy design, because the enterprise must decide which devices are approved, how many devices a person can register, and how revocation works when employment or role changes.
That shift matters because enterprise friction often appears at the edges: lost devices, temporary replacements, contractors, shared workstations, and users who need strong authentication from more than one endpoint. A model that looks efficient in pilot can become expensive in production if it does not match the organisation’s device turnover and support model.
For organisations building stronger access discipline, the Top 10 NHI Issues is a helpful reference for lifecycle and governance patterns that also explain why unmanaged lifecycle transitions create avoidable exposure. On the external side, NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Benchmarks both reinforce the value of consistent access governance and secure configuration in enterprise deployments.
Per-user provisioning is often the better enterprise default when the main requirement is scalable distribution, predictable support, and fewer rebind events during hardware changes. Per-device provisioning is better when the endpoint itself is the security boundary and device uniqueness is more important than user convenience.
Risk and Threat Considerations
The main risk with per-device provisioning is operational lock-in: if the device is lost, broken, wiped, or replaced, access may fail until the authenticator is reissued and re-enrolled. The main risk with per-user provisioning is entitlement sprawl: if device registration, approval, and revocation are weak, the user may accumulate more usable endpoints than the organisation intended.
Failure mechanism: Device-bound authenticators can create availability gaps during replacement or recovery, while user-bound models can accumulate unmanaged approved devices if enrolment and deprovisioning are not tightly controlled.
Impact: The result can be service desk overload, slower offboarding, inconsistent authentication state across endpoints, and a larger attack surface if a compromised device remains trusted longer than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Covers how access is provisioned and controlled for users and devices. |
| Recommendation — Align provisioning with identity and access control processes so enrolment, approval, and revocation stay consistent. | ||
| CIS Controls v8 | CIS-06 — Access Control Management | Addresses account and access lifecycle management, including authorised access paths. |
| Recommendation — Define approved-device and approved-user access paths, then revoke them promptly when they change. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Identity proofing and binding affect how strongly the authenticator is tied to the person. |
| Recommendation — Set proofing and binding requirements that match the assurance needed for user-based authentication. | ||
| NIST Zero Trust (SP 800-207) | PA — Policy Decision Point and Access Policies | Zero trust policies determine which devices and users are permitted to authenticate. |
| Recommendation — Use policy checks to permit only approved users and approved device states at authentication time. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Provisioning models affect how authenticator material is issued, replaced, and revoked. |
| NHI-03 — Identity Lifecycle and Offboarding | The question is fundamentally about lifecycle handling for authenticator assignment and removal. | |
| Recommendation — Track authenticator issuance and revocation so replaced or retired credentials do not remain usable. Automate enrolment, replacement, and offboarding so provisioning state stays accurate across the workforce. | ||
Practitioner Guidance
What to verify: Test whether your provisioning model matches the real endpoint lifecycle. If users routinely swap laptops or need multiple approved devices, verify that enrolment, recovery, and revocation can be completed without manual exceptions becoming the norm.
Decision rule: If the business values portability and rapid replacement, default toward per-user provisioning with strict device approval rules. If the business values a single hardened endpoint as the trust anchor, per-device provisioning may be acceptable, but only with a clear replacement and recovery process.
Common mistake: Treating provisioning choice as a one-time setup issue instead of a lifecycle decision. The model should be judged by offboarding speed, replacement handling, and how much administrative debt it creates at scale.
Practitioner takeaway: Choose the model that matches your real operational pattern, not the one that looks simplest on day one, because the right answer is the one that keeps authentication both manageable and reliably recoverable across the full device lifecycle.
Related resources from NHI Mgmt Group
- What is the difference between TOTP MFA and device-bound authentication?
- What is the difference between domain-wide delegation and per-user OAuth access in an enterprise knowledge retrieval setup?
- What is the difference between device binding and risk-based authentication in user verification?
- What is the difference between per-user MFA and Authentication Methods Policy in Azure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
