Treat the credential types as complementary, not interchangeable. Mobile credentials can serve the broad user base, while PKI or physical cards remain necessary where workstation access, restricted spaces, or elevated assurance requirements apply. The governance task is to assign each method a clear use case.
How to Govern Mobile Credentials, PKI, and Physical Cards as One Access Portfolio
Teams should govern these methods as a portfolio with different trust properties, not as competing products. The key decision is not which credential is “best” in the abstract, but which credential is appropriate for a specific access path, assurance level, and operational context. That means defining the intended use case, the assurance baseline, and the fallback when a method is unavailable or revoked.
Mobile credentials are often the most practical default for broad user populations because they reduce card issuance friction and can fit modern device-centric workflows. PKI and physical cards remain important where stronger workstation binding, controlled facility entry, or higher-assurance authentication is needed. The governance model should make those boundaries explicit so users do not improvise with whatever credential happens to work.
For teams trying to decide where to place the line, the useful question is whether the credential is merely convenient or whether it is part of a controlled trust chain. Mobile credentials can be suitable for everyday access, but when access decisions affect shared workstations, restricted areas, or environments with higher assurance requirements, the policy should require the stronger method rather than treat it as optional.
Set Policy by Use Case, Assurance, and Recovery Path
Good governance starts with a written matrix that maps each credential type to a concrete access scenario. The matrix should specify where mobile credentials are allowed, where PKI is required, where physical cards are required, and where two methods must coexist for the same user population. This avoids the common failure mode where different sites, business units, or facilities create inconsistent local rules.
That policy should also define the recovery path when a phone is lost, a card is forgotten, or a certificate is nearing expiry. The operational question is not only “can the user get in?” but “how is access restored without weakening the assurance model?” Mobile-first programmes often fail when exception handling becomes the real access policy.
Mobile credential lifecycle handling matters because issuance, renewal, and revocation must stay aligned across devices, cards, and PKI-backed identities. Where credentials expire or are rotated, teams need a way to preserve continuity without leaving old methods active longer than intended.
How to Prevent Credential Overlap from Becoming Control Drift
The biggest governance risk is allowing overlap to turn into ambiguity. If the same person can use mobile credentials, PKI, and cards interchangeably without clear rules, control owners lose visibility into which method actually protects which asset. That weakens auditability, complicates incident response, and makes it harder to prove that higher-risk areas really received higher assurance.
Another failure mode is assuming that a credential with broad convenience can substitute for a credential with a stronger control purpose. A phone credential may be acceptable for routine user access, but it should not quietly expand into workstation login, restricted-area entry, or elevated access without a formal review. Governance should therefore tie each method to an approved control boundary and require re-approval before the boundary moves.
For mobile, the underlying trust is usually the device and the managed identity state around it, which is why certificate lifecycle management is a useful model when PKI is part of the stack. Teams should track expiry, renewal, and revocation as operational controls, not just technical housekeeping.
Risk and Threat Considerations
When teams blend mobile credentials, PKI, and cards without clear boundaries, the main risk is control drift. Users take the easiest path, help desks create exceptions, and assurance levels quietly collapse until the organization can no longer say which access path was used for a given system or space.
Failure mechanism: Overlap between methods creates inconsistent enforcement, weakens revocation discipline, and increases the chance that a lower-assurance credential is accepted where a stronger one was intended.
Impact: The result can be unauthorized access, weaker audit evidence, slower incident containment, and a broader blast radius if one credential type is lost, cloned, or abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Mobile, PKI, and card use all depend on user authentication choices. |
| IA-3 — Device Identification and Authentication | Mobile credentials and cards often rely on device or badge-bound trust for access. | |
| IA-5 — Authenticator Management | Credential issuance, rotation, revocation, and expiry are central to mixed credential governance. | |
| Recommendation — Assign each access path to the correct authentication method and enforce it consistently. Bind access decisions to the device or card trust signal that the site actually requires. Define issuance, renewal, revocation, and expiry rules for each credential type. | ||
Practitioner Guidance
What to verify: Confirm that every credential type has a named owner, an approved use case, and a documented exception path. If a site or application cannot explain why it accepts a given method, that is a governance gap rather than a convenience choice.
Decision rule: If an access path protects a workstation, restricted area, or high-assurance function, require the credential with the strongest control fit and treat mobile convenience as secondary. If the use case is ordinary user access, keep mobile as the default only when revocation and recovery are operationally reliable.
What good looks like: Users can understand which credential to use without guessing, auditors can trace access decisions back to policy, and exceptions are rare, time-bound, and reviewed. The best programmes make the portfolio simple to use while still preserving distinct trust levels.
Practitioner takeaway: Govern these methods by boundary, not by preference, because the real control objective is to preserve assurance while giving users the least burdensome credential that still fits the risk.
Related resources from NHI Mgmt Group
- How should organisations govern mobile credentials in physical access programmes?
- How should security teams implement PKI in payment ecosystems that span cards, APIs, and mobile wallets?
- How do security teams decide whether to centralise FIDO2, PKI, and physical access credentials in one workflow?
- How should security teams govern non-human identities alongside human accounts?