NIS2 Offboarding Requirements: Identity Lifecycle and the JML Obligation

How NIS2 and CIR 2024/2690 govern joiner, mover, and leaver processes — provisioning, deprovisioning, access reviews, HR security clauses, and asset recovery.

← Back to hub · Prev: Access control · Next: Authentication & MFA →

Legal basis: NIS2 Art. 21(2)(i) (human resources security, access control, asset management) · CIR (EU) 2024/2690 Annex 10.1–10.4 (HR security), 11.2 (management of access rights), 12.5 (deposit, return or deletion of assets on termination).

TL;DR (🔧 Engineering / 📋 GRC): NIS2 treats the human/identity lifecycle as a security control. Background-check people before granting access (10.1), bind security duties into employment terms (10.2), keep a disciplinary process for violations (10.3), and withdraw access and recover assets when people leave or change roles (10.4, 11.2, 12.5). The two failure modes auditors hunt for are standing access that outlived its need (movers who accumulate, leavers never deprovisioned) and no periodic recertification. Automate Joiner-Mover-Leaver from an authoritative HR source and review access regularly.

1. Why lifecycle is a NIS2 obligation, not hygiene

Recital 22 of the Implementing Regulation states the intent plainly: to stop employees misusing access rights to cause harm, entities should apply personnel security measures and background verification, maintain a disciplinary process, and manage the security implications of people joining, moving, and leaving. Combined with the management of access rights clause (11.2) and return/deletion of assets on termination (12.5), NIS2 effectively mandates a controlled Joiner-Mover-Leaver (JML) process.

The recurring risk NIS2 targets is privilege accumulation and orphaned access: people who change roles but keep old entitlements, leavers whose accounts linger, and contractors who never get offboarded. These are the access paths attackers and insiders actually use.

KINT's instant offboarding and joiner-mover-leaver automation address exactly this risk. The sections below describe what the regulation requires; the linked pages show how it can be automated.

2. The HR-security clauses (CIR section 10) 📋 🔧

⚠️ Privacy interlock: Background checks process personal (sometimes special-category) data. Keep them proportionate, role-justified, lawful under GDPR and national employment law, and documented. NIS2 expects screening; GDPR governs how you do it. Coordinate with your DPO.

3. Joiner — provisioning done right 🔧

Goal: the new identity exists, has exactly the right baseline access, and nothing sensitive lands before the gates are cleared.

1. Authoritative trigger: identity is created from the HR system of record (the joiner event), not by ad-hoc IT tickets. One source of truth prevents duplicate and rogue accounts.
2. Screening gate (10.1): background verification appropriate to the role is complete and recorded before privileged/sensitive access is granted.
3. Terms accepted (10.2): security/acceptable-use obligations acknowledged.
4. Birthright access by role (RBAC): baseline entitlements provisioned automatically from the person's role/department; everything beyond baseline goes through request + approval + justification (02 — Access control).
5. Unique identity + credential enrolment: unique account, MFA enrolled at first sign-in (04 — Auth & MFA).
6. Record it: who approved what, when — this is your evidence.

Contractors, temps, partners, and service accounts follow the same flow but with mandatory expiry dates and a named internal owner. Time-boxing non-employees is the cheapest way to prevent orphaned access.

4. Mover — the most-neglected, highest-risk transition 🔧

When someone changes role, department, or manager, access must change with them — old entitlements removed, new ones granted. NIS2's least-privilege expectation (11.2) is violated by privilege accumulation: the classic "she's been here eight years and can touch everything."

• Trigger mover events from HR (department/manager/job-title change).
• Apply the new role's birthright access and revoke the previous role's entitlements (don't just add).
• Force a targeted access review at the point of transfer for anyone moving into or out of sensitive/privileged roles.
• Re-check SoD: a move can create a new toxic combination of old + new rights.

5. Leaver — deprovisioning and asset recovery 🔧 📋

Goal: on (or before) the effective date, access is gone and assets are back. This is where CIR 11.2 (withdraw access) and 12.5 (deposit, return or deletion of assets on termination) combine.

Two traps:

• Disable ≠ deprovision. Disabling the SSO account can leave standalone app logins, API keys, and cloud access live. Map every place the identity has access and close them all.
• Federated ≠ everywhere. Apps with local accounts outside SSO are the usual source of live leaver access. Inventory them (links to non-human/local-account hygiene in 02).

6. Access reviews & recertification 🔧 📋

CIR 11.2 requires access rights to be reviewed (and the broader CIR pattern requires review "at planned intervals and after significant changes or incidents"). Recertification is how you catch the accumulation and orphan problems above and how you generate periodic evidence.

A workable cadence (tune to risk — this is a recommended baseline, not a fixed legal figure):

Make reviews decision-forcing: reviewers must explicitly approve or revoke each entitlement, revocations are actioned automatically, and the full review record is retained. A review that produces no revocations and no audit trail is a red flag, not a clean bill.

7. Implementation notes (vendor-neutral) 🔧

Examples, not endorsements.

• HR-driven provisioning: Workday/SuccessFactors/HiBob → IdP via SCIM or an IGA connector, so joiner/mover/leaver events flow automatically.
• IGA for reviews & requests: SailPoint, Saviynt, Omada, Microsoft Entra ID Governance (access reviews + access packages with expiry), Okta Identity Governance.
• Deprovisioning reach: ensure the IdP/IGA actually de-provisions downstream apps (SCIM deprovision, app connectors), not just the directory account.
• Local-account discovery: periodic reconciliation between IdP and each system to find accounts not tied to an active identity (orphan detection).
• Asset return (12.5): MDM/endpoint tooling to remote-wipe/retire devices; ITSM workflow to track physical return and secure deletion.

Design rule: every lifecycle state change should be event-driven from an authoritative source and leave a record. Manual JML is the root cause of most access findings.

8. Evidence an auditor will ask for 📋

• The JML procedure and HR-security policy (covering 10.1–10.4).
• Background-check records (existence and proportionality; redacted as needed for privacy).
• Sample joiner, mover, and leaver cases end-to-end with timestamps (grant/modify/revoke).
• Deprovisioning timeliness metric (e.g., time-to-disable after termination) and exceptions.
• Access review/recertification records with explicit approve/revoke decisions and resulting actions.
• Asset return/deletion records (12.5) for recent leavers.
• Orphaned/local account reconciliation results.

Common gaps that become findings

• Leavers disabled in SSO but still active in standalone apps, VPN, or cloud consoles.
• Movers accumulate entitlements; no transfer-time review.
• Background checks done informally with no record, or not gated before access.
• Access reviews are "rubber-stamped" — no revocations, no retained evidence.
• Contractors/service accounts with no expiry and no owner.
• Assets (devices, tokens, removable media) not tracked back from leavers (12.5 gap).

Sources

• NIS2 Art. 21 — risk-management measures
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (Annex §10.1–10.4, §11.2, §12.5; recital 22)

FAQ

What are the NIS2 offboarding requirements for departing employees? Under CIR 11.2 and 12.5, entities must withdraw all access rights on or before the effective exit date, invalidate sessions and tokens (not just disable the account), revoke any privileged access immediately, recover or securely delete devices and credentials, and confirm surviving confidentiality obligations under CIR 10.4. Every action must be recorded with a timestamp and retained as evidence.

Does NIS2 require automated deprovisioning? The regulation is technology-neutral — it requires timely, demonstrable deprovisioning, not a specific tooling approach. In practice, manual processes are the root cause of most deprovisioning findings because delays are inevitable and records are inconsistent. HR-driven automation, with event-based triggering from the HR system of record, is the standard way to meet the timeliness and evidence requirements at scale.

What counts as an "orphaned account" under NIS2? Any account or access right that no longer corresponds to an active, authorised identity with a current business need. This includes leavers never offboarded, contractors whose access outlasted their engagement, movers who still hold entitlements from previous roles, and service accounts with no identifiable owner. CIR 11.2 requires all such access to be reviewed and revoked; orphan reconciliation is a standard auditor request.

How often does NIS2 require access recertification? The CIR requires periodic review but does not fix specific intervals — the frequency is risk-based. The standard baseline is quarterly for privileged and admin accounts, quarterly to semi-annually for access to high-classification or critical systems, annually for standard application access, and quarterly for non-human and third-party accounts. Reviews must produce explicit approve/revoke decisions and a retained record; a review with no revocations and no documentation is a finding.

Does NIS2 require background checks on employees? CIR 10.1 requires background verification proportionate to the role and the entity's security policy. This typically means identity verification, reference checks, and where appropriate and lawful under national employment law and GDPR, past-duties or criminal-record checks before granting privileged or sensitive access. The screening must be recorded, and re-screening applies to role changes into sensitive positions where lawful.

What is the difference between disabling and deprovisioning under NIS2? Disabling an SSO account prevents interactive login to federated apps but leaves any standalone app accounts, API keys, cloud console access, and active sessions live. NIS2 Article 21 via CIR 11.2 requires actual revocation of access rights across all systems, not just the directory record. Full deprovisioning means closing every access path — federated and non-federated — and invalidating active sessions and tokens.

How KINT helps: KINT automates the joiner, mover, and leaver access lifecycle across your SaaS apps and produces signed, timestamped access-review evidence mapped to SOC 2 CC6 — the kind of evidence NIS2 Article 21 expects you to be able to show. It is early-stage and self-serve, and runs without an identity provider. See how KINT handles the lifecycle or view instant offboarding, or book a 15-minute walkthrough.