Ariovis

Use case · NIS2 and the French ReCyF

Contributing to NIS2 compliance across identities and access

NIS2 is not limited to IAM. Identity and access management is, however, an area where organisations can turn security principles into concrete controls: knowing who has an account, why it exists, how its holder authenticates, what they can do, how their rights change and when those rights are removed.

Published by France’s ANSSI in September 2026, the French “ReCyF in practice — Identity management” guidance structures this scope around ReCyF security objective 10: managing user identities and access to information systems. An IAM programme can industrialise many of these mechanisms when it works with Access Management, directories, secrets management, PAM and, for machine identities, PKI.

The outcome sought by ANSSI

The guidance aims to prevent illegitimate users from accessing information-system resources and to make every action unambiguously attributable to a user or automated process. It expresses this goal through three security functions, complemented by traceability.

Lifecycle management cuts across all four: when an account no longer has a reason to exist, access must be neutralised quickly and rights removed. The guidance states that it does not replace the ReCyF, is neither prescriptive nor exhaustive, and explains intended outcomes through implementation examples.

  1. 01

    Identify

  2. 02

    Authenticate

  3. 03

    Authorise

  4. 04

    Trace

Lifecycle management connects all four functions, from creation to deactivation.

From the French ReCyF to an IAM workstream

This matrix connects ReCyF objective 10 measures to mechanisms and possible evidence. It is neither an exhaustive interpretation of NIS2 nor an architecture prescription.

  • Identification — 10.A.1-EI/EE to 10.A.6-EI/EE

    Intended outcome

    Tie every access path to a clearly identified human identity or automated process.

    IAM mechanism

    Identity repository, unique identifiers, owned technical accounts, identity/account reconciliation and lifecycle.

    Complementary capabilities

    Directory, logging and PAM where relevant.

    Possible operational evidence

    Identity and account inventory, technical-account owners, creation and deactivation history.

  • Authentication — 10.B.1-EI/EE to 10.B.6-EI/EE and 10.B.7-EE

    Intended outcome

    Adapt authentication assurance to risk and control secrets.

    IAM mechanism

    Connect identity context to access policy.

    Complementary capabilities

    IdP / Access Management, MFA, federation, secrets vault and PAM.

    Possible operational evidence

    MFA coverage, authentication policies, population-specific rules, administration and change logs.

  • Access rights — 10.C.1-EI/EE to 10.C.4-EI/EE

    Intended outcome

    Limit access to actual need and keep it coherent over time.

    IAM mechanism

    Roles, entitlement rules, requests, approvals, provisioning, recertification, revocation and deprovisioning.

    Complementary capabilities

    Applications, directories and fine-grained authorisation when context must inform the decision.

    Possible operational evidence

    Entitlement catalogue, owners, review campaigns, certification decisions and revocation history.

SSO simplifies authentication; it does not replace authorisation governance. An authenticated person should not automatically gain access to every federated resource.

What IAM can automate

An HR source or another authoritative repository can trigger Joiner / Mover / Leaver events. On arrival, IAM creates the identity, applies entitlement rules and provisions the required accounts. On a move, it recalculates rights from the new situation and removes entitlements that are no longer needed.

On departure, or during an absence requiring suspension, the process can trigger account deactivation and entitlement removal under defined rules. Recertification campaigns then periodically compare actual rights with an up-to-date theoretical need.

Automation is reliable only when sources, owners, rules and responsibilities are defined. Automating ambiguous data or an ownerless rule mainly accelerates the spread of errors.

What IAM cannot do alone

An IGA platform does not replace an identity provider or MFA. An IdP does not govern entitlements by itself. PAM does not cover the entire identity lifecycle. IAM alone does not harden Active Directory and does not replace PKI for issuing, renewing or revoking certificates.

None of these capabilities, alone or simply stacked together, establishes NIS2 compliance. Their value comes from a coherent chain of responsibilities and controls that can produce evidence on the identity and access scope.

  • IGA

    Govern identities, entitlements and their lifecycle.

  • Access Management

    Authenticate and enforce policies along access journeys.

  • PAM

    Control selected sensitive secrets, accounts and privileges.

  • Directories

    Hold and execute part of the accounts, groups and policies.

  • PKI

    Establish and maintain certificate-based trust.

  • Logging and monitoring

    Retain, correlate and use traces.

Explore the controls

Each page isolates a technical and organisational workstream while retaining its link to objective 10 of the French ReCyF.

Capabilities to combine

The right combination depends on existing systems and risk; these capabilities intervene at different points in the control chain.

Sources and guidance

The supplied French guidance is the primary source. Other links point only to verified official ANSSI resources relevant to individual controls.

Turn objectives into verifiable controls

We can help frame responsibilities, processes and expected evidence across your identity and access scope.

Talk to Ariovis