How do organisations know if JML is working across badges and applications?

They should measure revocation latency in both domains and compare the badge to the account. If the last physical credential remains active after the leaver event, the programme is only partially automated. The best signal is whether one lifecycle event produces one complete offboarding record.

Measuring whether JML is actually working across the badge and the app

The right test is not whether the process exists on paper, but whether one leaver event reliably closes both physical and digital access. Measure the time to revoke each credential type, then compare the badge record with the application account record. If one side consistently lags, JML is fragmented rather than complete.

That comparison matters because the control objective is end-to-end removal of access, not isolated task completion. A badge that remains active after the account is closed, or an account that lingers after the badge is deactivated, both indicate a lifecycle gap that can create residual access.

For teams building the process, the most useful Joiner-Mover-Leaver (JML) Guide is the one that treats offboarding as a single workflow with multiple revocation targets. The same lifecycle logic is reinforced in IAM and IGA Basics, which ties provisioning, access review, and entitlement governance together.

What a matched badge and account timeline tells you

A good JML signal is temporal alignment. The physical credential should deactivate within the same business event window as the application account, not at some later cleanup step. When both changes are recorded against the same leaver event, you can show that the organisation is governing access as one lifecycle rather than two disconnected systems.

That is why revocation latency is more informative than a simple yes/no checklist. It captures whether the badge system and the application environment are operating from the same authoritative offboarding trigger, and whether the downstream systems actually honour that trigger without manual intervention.

If the last physical credential remains active after the leaver event, the organisation should treat that as partial automation, not a minor exception. The same is true if the application account is disabled but the badge is not, because the person still retains a route to physical entry that may support later misuse or social engineering.

How to tell the programme is complete, not just automated in one place

The strongest indicator is whether one lifecycle event produces one complete offboarding record with all access changes attached. That record should show the badge revoked, the application account disabled, and any related exceptions resolved or formally approved. If the records do not reconcile, the organisation cannot prove that JML is operating across the full access surface.

In practice, the most common failure is ownership drift: facilities, HR, IAM, and application teams each close their own tickets, but no one verifies that the event closed everywhere. A complete JML signal therefore depends on cross-system correlation, not just on local task closure.

This is exactly the kind of lifecycle linkage described in the NHI Lifecycle Management Guide, which focuses on provisioning, rotation, and offboarding as connected control states. Where organisations need a cautionary example of what happens when offboarding fails to catch a lingering credential, Coupang Signing Key Breach shows why delayed revocation can become a real exposure.

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-4 — Identifier Management	JML depends on consistent lifecycle handling of physical and application identities.
	IA-5 — Authenticator Management	Revocation latency reflects whether credentials and authenticators are promptly retired after leaver events.
	AC-2 — Account Management	Account disabling is a core part of JML closure for application access.
Recommendation — Centralise identifier lifecycle changes so badge and account removal follow the same authoritative event. Track and retire authenticators on a defined timetable after offboarding. Disable accounts promptly and verify deactivation is tied to the leaver workflow.
ISO/IEC 27001:2022	A.5.16 — Identity management	JML is an identity lifecycle control across physical and digital access.
	A.5.18 — Access rights	The question is about revoking access rights at offboarding time.
Recommendation — Maintain identity records so leaver actions propagate across systems without delay. Revoke access rights when employment or role ends and confirm completion.

Practitioner Guidance

What to measure: Track median and worst-case revocation latency separately for badges and applications, then compare them by leaver cohort. The useful question is not only whether access was removed, but whether the two removals happened within the same operational window.

What to verify: Require evidence that the same leaver event closed every access path, including physical entry and application login. If the badge and account histories do not reconcile to one offboarding record, treat the JML control as incomplete even if each team reports success independently.

Common mistake: Organisations often optimise the fastest system and assume the slower one will “catch up” later. In JML, delayed catch-up is the failure mode, because the residual credential is still usable during the gap.

Practitioner takeaway: A mature JML programme is measurable when the identity event, the physical credential event, and the application event converge into one auditable closure, with no lingering access path left behind.