In the context of the NIS2 Directive, identity management processes – particularly onboarding and offboarding – are no longer the exclusive domain of HR and operational IT departments. From a cybersecurity engineer’s perspective, every new employee, contractor or external partner represents a potential point of entry into the infrastructure. Incorrectly granted permissions, delays in deprovisioning or a lack of control over the account lifecycle (JML – Joiner-Mover-Leaver) constitute direct breaches of the cyber hygiene and access control requirements imposed by NIS2.

From an engineering perspective, automating onboarding processes using the Okta platform enables the implementation of the Least Privilege Access and Zero Trust principles from the user’s first day at work.

Onboarding in the light of the requirements of the NIS2 Directive

Article 21 of the NIS2 Directive requires critical and important entities to implement ‘appropriate and proportionate technical and organisational measures to manage risk’. In the area of human resources management and access control, this translates into specific objectives:

  • The principle of least privilege: From the moment they log in, a newly recruited user should only have access to the resources necessary to carry out their tasks.
  • Speed and consistency: Eliminating the need to create accounts manually reduces the risk of human error (e.g. accidentally granting administrative rights).
  • Full auditability: Every change to permissions and the fact that they have been granted must be recorded in system logs that are ready to be presented to an auditor.

HR-as-a-Source (HRaR) integration – the start of the cycle in Okta

The cornerstone of secure onboarding within the Okta architecture is the concept of HR-as-a-Source (HRaR). The HR and payroll system becomes the single source of truth for identity within the organisation.

  1. Identity onboarding: The recruiter enters the new employee’s details into the HR system. Okta automatically detects the new record via the API.
  2. Creating an account in Okta Universal Directory: Based on attributes (e.g. department, role, location, contract type), Okta generates a Unique Identifier (GUID) and assigns the user to the relevant logical groups.
  3. Automatic Provisioning (SCIM): Thanks to its support for the SCIM (System for Cross-domain Identity Management) protocol, Okta automatically creates accounts in target applications (Microsoft 365, Jira, Salesforce, AWS/Azure environments) without the need for an administrator.

From the NIS2 perspective, this process ensures that the access profile is closely linked to employment status and automatically assigned to the relevant security policies.

Secure ‘Day 0’ and MFA factor registration

One of the most challenging aspects of secure onboarding is an employee’s first login, when they do not yet have their authentication credentials set up.

  • Okta FastPass and Phishing-Resistant MFA: From day one, we require users to register for the passwordless FastPass mechanism, which is based on FIDO2/WebAuthn or YubiKey hardware keys.
  • Customisable Onboarding Workflows: When a user logs in for the first time, they go through a dedicated registration process. Until they have registered the required, strong (phishing-resistant) MFA factors, access to corporate applications remains blocked.
  • Secure credential transfer: The use of mechanisms such as Okta Temporary One-Time Password (TOTP) or one-off activation links sent to a verified channel eliminates the risk of account takeover before work formally begins.

Okta Workflows and Governance: Precise control over permissions

The advanced onboarding scenarios set out in the NIS2 Directive require access levels to be tailored according to technical role. Using Okta Workflows and Okta Identity Governance (OIG), security engineers can implement automated approval workflows:

  1. Basic access (Birthright Access): Every employee receives a standard suite of tools (email, instant messaging, staff portal).
  2. High-risk access (Just-In-Time Access): If a developer requires access to production environments or a database, access is not granted permanently during onboarding. Instead, the OIG allows them to request temporary access (JIT), which requires approval from the Lead Security Engineer or the CISO.
  3. Automatic role change (Mover): When an employee changes departments, Okta automatically revokes permissions from their old role and grants new ones, preventing the phenomenon known as privilege creep (the accumulation of permissions).

Offboarding – the other side of the coin in the context of NIS2

There can be no secure onboarding without equally rigorous offboarding. From an architectural perspective, revoking an employee’s access must be immediate and deterministic.

When the HR department changes an employee’s status to ‘inactive’, Okta Lifecycle Management immediately:

  • Deactivates the account in the Okta Universal Directory.
  • It sends a Universal Logout signal to terminate active sessions across all SaaS/Cloud applications.
  • It blocks accounts in target applications via SCIM.

Traditional, manual offboarding left inactive accounts open for days, months and sometimes even years. Automation with Okta reduces this time to seconds, meeting the most stringent NIS2 operational requirements.

Why should you implement secure Lifecycle Management with Softinet?

Building a secure identity lifecycle requires more than just purchasing a licence – a thorough understanding of native API integrations, SCIM/SAML/OIDC protocols and security engineering methodologies is essential.

Softinet engineers help organisations map their existing HR processes and transform them into automated, auditable workflows within the Okta Identity Cloud. You ensure compliance with NIS2, minimise the workload on your operational IT team and can be confident that identities within your organisation are protected from the first day of employment to the last.