They should offboard them as a single identity object, with revocation covering building access, system access, and any tied certificates at the same time. Splitting the lifecycle between facilities and IAM teams creates residual access that is easy to miss.
Why a dual-purpose card should be treated as one identity object
A card that opens a door and also unlocks systems is not two separate access problems. It is one credentialed identity with two enforcement points, so the lifecycle has to stay unified. If facilities revoke the badge but IAM leaves the digital entitlement active, or vice versa, the organisation creates a gap where one path is closed while the other still works.
The practical rule is to govern the card as a single joiner, mover, leaver object, even if multiple teams touch it. That means one record, one owner, one revocation event, and one clear source of truth for status. The control objective is consistency across physical access, logical access, and any certificate or token bound to the same card.
Where organisations get this wrong is not in the technology, but in the operating model. Physical security often thinks in badges and doors, while IAM thinks in accounts and sessions. A dual-purpose card forces those views to meet, because the same lifecycle decision must drive both access domains at the same time.
What the lifecycle has to cover from issue to offboarding
Governance starts at issuance. The card should be bound to a named owner, a defined purpose, and a documented set of access paths it can activate. If the card supports certificates, those certificates should be registered as dependent credentials, not treated as separate exceptions that drift outside the normal identity lifecycle.
During the active life of the card, changes should be handled as a single update event. If the person changes role, location, or employment status, the organisation should review the physical access profile, the logical entitlements, and any card-backed certificate state together. That avoids a common failure mode where one team approves a change and another team never receives the dependency signal.
Offboarding is the most important control point. The card should be revoked first or at least atomically with account disablement, and any tied certificates should be invalidated in the same process. IAM and IGA Basics is useful here because it frames the problem as lifecycle governance, not just access removal. If a card is still trusted by one system after the person has left, the identity has not actually been retired.
How to avoid split ownership and hidden residual access
The strongest governance model is a single workflow with coordinated execution, even if separate teams approve parts of it. Facilities can still manage door policy and IAM can still manage digital entitlements, but neither team should be allowed to close the ticket independently when the card remains active in another control plane.
That makes ownership the critical design choice. The business should assign one accountable owner for the card lifecycle, with explicit handoffs to facilities, IAM, and certificate management only as execution steps. For enterprises that want a broader access-model view, Authorisation Models Guide helps position the digital side correctly, while Financial Services Identity Security Guide shows why cross-domain access control becomes especially sensitive in regulated environments.
The test is whether revocation is observable end to end. If the organisation cannot prove that physical badge state, system login state, and certificate validity all changed together, it should treat the control as incomplete. That is the point where residual access becomes a governance defect rather than a theoretical inconvenience.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Card-linked certificates and tokens require coordinated lifecycle control and revocation. |
| IA-9 — Service Identification and Authentication | Dual-purpose cards may authenticate to systems through device or service trust paths. | |
| AC-2 — Account Management | The question is fundamentally about unified provisioning and offboarding of access rights. | |
| Recommendation — Revoke card-bound authenticators together when the identity is offboarded. Bind access decisions to the authenticating entity and disable all dependent access paths. Use one lifecycle process to disable physical and logical access at the same time. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires consistent access governance across physical and logical access paths. |
| A.5.16 — Identity management | A dual-purpose card is an identity object that needs a single authoritative lifecycle. | |
| Recommendation — Align access rules so revocation affects every enabled access channel. Maintain one identity record for the card and retire it as a single object. | ||
Practitioner Guidance
What to verify: Confirm that one workflow can disable every access path the card enables, including badge access, system authentication, and certificate or token dependencies. If any of those actions require separate tickets or separate owners to finish, the model is already too fragmented.
Decision rule: If the card can still authenticate to anything after the user is offboarded, treat the card as an identity object that was not fully revoked. Do not accept partial completion as closure.
Common mistake: Teams often rotate the digital account and forget the physical credential, or they collect the badge but leave the system entitlement or certificate active. The safest pattern is atomic retirement, not coordinated delay.
Practitioner takeaway: Dual-purpose cards fail when organisations manage them by function instead of by lifecycle. The control succeeds only when one revocation action reliably shuts down every authority the card carries.
Related resources from NHI Mgmt Group
- How should organisations govern identity when digital access and physical access are split across different systems?
- How should organisations replace physical ID cards without creating new access control gaps?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?