Use case · NIS2 · Multinational groups
NIS2 for multinational groups: shared IAM, entity-specific obligations
A multinational group may share its information systems, identity platforms and cybersecurity policies without all its legal entities necessarily being subject to the same national rules. The NIS2 Directive provides a common European framework, but its application depends on the activities performed, the entities concerned and the relevant jurisdiction rules. A subsidiary in Belgium does not automatically have the same regulatory obligations as its French parent company.
This regulatory diversity does not require the group to deploy an entirely different IAM architecture in every country. Identity repositories, lifecycle processes, entitlement governance, authentication policies and operational evidence can often be shared. The challenge is to define which controls can be managed centrally, which decisions belong to local entities and how each organisation can demonstrate its own responsibilities.
Does NIS2 apply to the group or to each subsidiary?
The first challenge is to identify the entities concerned. A subsidiary does not automatically fall within the scope of NIS2 because its parent company does, nor does a holding company fall within scope solely because of the activities of its investee companies. Conversely, an entity’s size cannot always be examined in isolation: European rules on linked or partner enterprises may affect the assessment of thresholds.
An international organisation must therefore examine the activities and structure of each entity, the criteria for falling within scope, any exceptions and the jurisdiction of national authorities. A single organisation may encompass several regulatory situations, including essential entities, important entities and entities outside scope.
Legal mapping can be undertaken with compliance teams and appropriately qualified advisers. It then provides IAM teams with the actual scope of the identities, applications, processes and responsibilities to be governed.
The six dimensions of group-wide NIS2 mapping
- Legal person
- Identify companies, establishments and responsibilities
- Activity
- List the services actually provided and the sectors concerned
- Criteria for falling within scope
- Examine thresholds, exceptions and linked or partner enterprises
- Territorial scope
- Identify Member States of establishment and cross-border situations
- Jurisdiction
- Determine the relevant authority or authorities under Article 26
- Obligations and evidence
- Identify applicable legislation, deadlines, responsible parties and supporting evidence
This mapping is an organisational and legal prerequisite. It should not be confused with a simple inventory of the countries where users or servers are located.
Which NIS2 authority has jurisdiction over a multinational?
Article 26 of the NIS2 Directive sets out several rules on jurisdiction. For entities under the general regime, establishment is the main connecting factor. An entity established in several Member States may be subject to several authorities, which have cooperation and mutual assistance mechanisms available to them.
Certain categories of activity follow specific rules. Providers of public electronic communications networks or publicly available electronic communications services are, in particular, subject to the jurisdiction of the Member States in which they provide their services. For several categories of digital service providers, including cloud providers, MSPs and MSSPs, the Directive instead uses the criterion of main establishment in the Union.
This distinction is crucial for groups that share cybersecurity capabilities. The location of the registered office, the IAM platform or the security monitoring centre is not always sufficient to identify the competent authority. The answer depends on the type of entity and the criteria specific to its activity.
General regime
- Principle
- establishment of the entity.
- Consequence
- an established presence in several Member States may result in jurisdiction in several countries.
Electronic communications
- Principle
- Member States where the services concerned are provided.
- Consequence
- several Member States may exercise jurisdiction depending on the activities.
Certain digital activities
- Principle
- main establishment in the Union under Article 26.
- Consequence
- a specific jurisdiction regime applies to the entity concerned, without automatically extending to all companies in its group.
Main establishment does not simply mean registered office
For the digital providers covered by Article 26, the main establishment depends first on where decisions on cybersecurity risk-management measures are predominantly taken. If this cannot be determined, the location of cybersecurity operations must be examined, followed by the establishment with the highest number of employees in the Union. The actual organisation of responsibilities must therefore be examined rather than considering only the registered office address.
Several countries, different timetables and supervision arrangements
The Directive establishes a common framework, but national legislation determines some of the implementation and supervision conditions. As at 19 October 2026, Belgium already applies its transposing legislation, while France continues its legislative process. A multinational operating in both countries cannot therefore mechanically apply the Belgian timetable to its French entities or assume that the absence of full transposition in France suspends the obligations of its Belgian entities.
The same caution applies to other European locations: applicable legislation, competent authorities, deadlines and sector-specific regimes must be checked for each situation. A group compliance timetable must retain these differences without preventing IAM teams from initiating common controls where these address the risks.
What should be shared in multinational IAM?
Centralisation is not an end in itself. An international organisation may have several HR sources, separate directories, local applications and business rules that do not lend themselves to full standardisation. An effective IAM architecture should instead define common constants, then allow entities to retain the decisions and exceptions for which they are responsible.
The shared foundation may cover identification conventions, lifecycle events, least-privilege principles, authentication requirements and evidence production. Local entities can retain responsibility for certain repositories, approval of sensitive access, business-specific requirements and justification of exceptions. This relationship must be explicit to prevent technical centralisation from creating ambiguous responsibilities.
This allocation is an architecture and governance model, not a regulatory allocation imposed by NIS2. Actual responsibilities must be defined according to the organisation, internal contracts, resources operated and applicable legislation.
Who decides, who executes and who responds to supervisory checks?
An international IAM programme requires governance that goes beyond the sole responsibility of the central technical team. The entities concerned must be able to identify those responsible for access to their resources, the teams executing operations and those retaining evidence. The group can define a common framework and take on part of the operations, but the entities’ responsibilities do not disappear as a result of this sharing.
An explicit responsibility model also helps avoid conflicting decisions. The group can ensure architectural consistency, while business teams and local managers approve access needs. IAM teams then implement those decisions in the systems concerned and make their results verifiable.
Example of allocating responsibilities within a group
This allocation is illustrative. It does not constitute a universal RACI imposed by NIS2. Legal obligations and notification responsibilities must be confirmed for each entity.
A single IAM operation can support several supervisory evidence files
One of the main challenges of an international programme is not producing additional documents, but making the operations actually performed verifiable. Revocation of access rights, access approval or a recertification campaign may form part of a common process while concerning resources operated by different entities. Evidence must therefore make it possible to understand the decision, its execution, the scope concerned and the person responsible for the resource.
An organisation can systematise this traceability without creating a different audit system for each country. IAM events can be collected in common formats, then linked to entities, applications, owners and local controls. This sharing facilitates checks while leaving the entities concerned responsible for presenting evidence suited to their applicable requirements.
Example: the departure of an employee with cross-border access
A person is employed by a French entity, works with a Belgian team and has permissions on applications administered at group level. Their departure therefore triggers operations in several systems and involves different resource owners.
- The authorised HR source reports the departure.
- IAM identifies the associated accounts and entitlements.
- Revocation rules and the necessary approvals are applied.
- Connectors execute operations in the applications concerned.
- Errors and exceptions are detected and handled.
- Events and decisions are retained together with their scope and responsible parties.
Ariovis analysis
The organisation benefits from systematising this process rather than asking each subsidiary to handle the same events manually. However, evidence must be retrievable for a given entity, application and period. A centralised log that cannot link operations to their responsible parties and resources remains difficult to use during a supervisory check.
This example is a fictitious educational scenario.
Three situations that change IAM programme design
Situation 1
Industrial group and national autonomy
An industrial group has central IT governance, but its subsidiaries retain separate HR sources, applications and approval workflows. Attempting to impose a single platform immediately can make the project more complex than necessary. The first task is to identify common identity events and controls, then define how each country will be integrated without removing local responsibilities.
The IAM roadmap can then rely on common rules, standardised interfaces and gradual orchestration. The group gains better visibility without requiring all entities to operate identically.
Situation 2
Deploying identity governance across two countries
An organisation extends its IGA system from one European location to a second, where user populations, applications and approval rules differ. The existing system provides a reusable foundation, but roles and responsibilities must be adapted. A purely technical duplication of the first deployment could obscure the new entity’s specific characteristics.
The architecture work involves retaining a consistent model while defining the exceptions, sensitive access rights and controls needed in each context. IGA then supports common governance rather than becoming a catalogue of rules copied from one country to another.
Situation 3
Digital service provider operating in several Member States
A digital service provider operates in several Member States and centralises some of its cybersecurity decisions. Before defining its regulatory organisation, it must determine whether its activities fall under the specific Article 26 regime relating to main establishment in the Union. The location of customers, servers or the registered office is not necessarily sufficient on its own to resolve this question.
IAM can be shared across its activities, but determining the competent authority and applicable obligations requires a separate legal assessment.
These three situations are illustrative educational scenarios.
How can you build a common, workable IAM roadmap?
An international IAM roadmap does not necessarily start with choosing a global platform. It starts with understanding entities, populations, existing processes and risks. Regulatory differences are then incorporated into governance that distinguishes common decisions from local adaptations.
The roadmap must be gradual. An organisation can first improve the reliability of its sources, secure the most sensitive access rights and systematise a few priority processes before extending the system to new subsidiaries or applications.
Phase 1
Assess responsibilities and scope
Identify the entities concerned, applicable frameworks, existing IAM processes, stakeholders and main dependencies.
Possible deliverables: mapping, responsibility matrix and priority IAM scope.
Phase 2
Define the group’s common IAM principles
Formalise the identity model, entitlement principles, access policies, lifecycle and evidence-production rules.
Possible deliverables: guiding principles, functional architecture, governance model and backlog.
Phase 3
Operationalise an initial scope
Connect priority sources and applications, improve lifecycle reliability, organise approvals and control sensitive privileges.
Possible deliverables: operational processes, configurations, connectors, tests and documentation.
Phase 4
Extend, audit and operate
Extend the system by entity or application, organise reviews, use evidence and incorporate changes into ongoing operations.
Possible deliverables: control campaigns, reporting, operational procedures and a continuous improvement roadmap.
Reuse controls without conflating frameworks
The NIS2 Directive includes requirements relating to access control policies, human resources security and authentication. National transpositions and frameworks may translate these objectives into specific controls and assessment arrangements. Some IAM mechanisms can therefore be reused across several entities without assuming that the references or expected evidence are legally identical.
A reliable identity repository, an enforced MFA policy, a revocation process or a recertification campaign are operational mechanisms that can support several control initiatives. The correspondence between these mechanisms and applicable legislation must nevertheless be documented and validated for each regulatory framework.
One IAM control, several reference frameworks
An international organisation may need to document its identity and access mechanisms against several frameworks. France's ReCyF, CyberFundamentals in Belgium and ISO 27001 address some similar risks, but use different wording, scopes and verification methods. Mapping them must therefore start with the operational control actually implemented, before examining the requirements to which it may contribute.
This matrix links six IAM workstreams to verified references, technical mechanisms and usable evidence. It supports design and preparation for assessments, without claiming to establish regulatory equivalence or certify an organisation's compliance.
The NIS2 Directive, particularly Article 21(2), provides for measures relating to access control policies, human resources security, asset management, cryptography and, where appropriate, multi-factor or continuous authentication.
Editorial reference: 19 October 2026 · Thematic mappings and operational contributions
Identities and lifecycleReCyF v2.510.A.1, 10.A.2, 10.A.5, 10.A.6CyFun 2025 · BasicPR.AA-01.1ISO 27001:2022A.5.16, A.5.18
Identify users, services and their accounts
- Problem addressed
- A person leaves the organisation, changes role or is no longer responsible for a service, yet their associated accounts and rights remain active. Conversely, some technical accounts exist without a clearly identified owner or purpose.
- Intended outcome
- Link each account to an identity or authorised process, then manage its lifecycle through to deactivation.
ReCyF — working version 2.5
10.A.1-EI/EE
Individual accounts for users and automated processes.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.A.2-EI/EE
Use of individual accounts restricted to their holders.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.A.5-EI/EE
Deactivation of accounts no longer required within the timescales defined by the account management policy.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.A.6-EI/EE
Account reviews at least annually, with correction of anomalies.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Management of identities and authentication information for authorised users, services and devices.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Identity management.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.5.18
Access rights, including their management and review.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
Governance starts with the ability to distinguish a person, an identity, an account and an entitlement. An IAM system can correlate these objects using authoritative sources and orchestrate joiner, mover and leaver events. It must also address technical accounts, whose legitimacy depends on a purpose and an owner, even when no person uses them directly.
Automation only adds value if events are reliable and target systems actually execute decisions. An incorrect HR source or an unmatched account can otherwise create a false sense of control.
IAM mechanisms
- Identity repository.
- Identity / account correlation.
- HR or other authoritative sources.
- Joiner / Mover / Leaver processes.
- Provisioning.
- Deprovisioning.
- Reconciliation and discrepancy checks.
Possible evidence
- Active account inventory.
- Link to an identity or process.
- Technical account owner.
- Creation and deactivation history.
- Leaver event records.
- List of unresolved discrepancies.
- Account review results.
- Typical responsibilities
- HR repository, IAM lead, account or application owners, operations.
- Possible indicator
- Proportion of active accounts with an identified owner or linked identity.
Nature and limitations of the mappings
A similar identity management objective, but no demonstrated equivalence of lifecycle arrangements or review frequency.
Thematic mapping, subject to the applicability defined within the ISMS.
Automation only adds value if events are reliable and target systems actually execute decisions. An incorrect HR source or an unmatched account can otherwise create a false sense of control.
Technical detail in the context of France’s ReCyF.
Authentication and secretsReCyF v2.510.B.1 to 10.B.6; 10.B.7-EE for the exceptionCyFun 2025 · BasicPR.AA-03.2ISO 27001:2022A.5.17, A.8.5
Authenticate using risk-appropriate mechanisms
- Problem addressed
- An organisation has an authentication policy but does not know precisely which access routes are protected, how exceptions are managed or when secrets must be replaced.
- Intended outcome
- Manage authentication mechanisms, their coverage, secrets management and documented exceptions.
ReCyF — working version 2.5
10.B.1-EI/EE
Authentication mechanism using at least one secret element.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.2-EI/EE
Changing default secrets before bringing systems into service.
Thematic mapping · Identifier and applicability verified in the official document
The text also requires checking with the supplier that the means and rights needed to make the change are available.
Version de travail 2.5 du 17 mars 202610.B.3-EI/EE
Renewal of a shared account's secret element when a user of that account is removed.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.4-EI/EE
Knowledge of secret elements restricted to authorised users.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.5-EI/EE
Compliance with applicable recommendations on authentication factors and their management.
Thematic mapping · Identifier and applicability verified in the official document
The text addresses complexity and renewal frequency according to ANSSI recommendations, taking account of the maximum technically possible.
Version de travail 2.5 du 17 mars 202610.B.6-EI/EE
Risk reduction measures where a secret element cannot be changed for technical or operational reasons.
Thematic mapping · Identifier and applicability verified in the official document
This exception requires appropriate access control and reduction of the risk associated with the fixed secret; additional traceability falls under 10.B.7-EE.
Version de travail 2.5 du 17 mars 202610.B.7-EE
Additional traceability under the exception provided for in the preceding control, for essential entities.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-03.2 — Basic
MFA required for remote access to the organisation's networks.
Thematic mapping · Documentary verification to be confirmed
The scope stated in the brief remains to be confirmed in the Basic booklet: the indexed Key Measures annex uses different wording for 2025. The detailed booklet could not be read (HTTP 403).
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.17
Authentication information.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.5
Secure authentication.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
An authentication policy is not measured solely by the presence of MFA. It must make clear which journeys are protected, which mechanisms are used, how exceptions are authorised and how authentication information is administered. Technical secrets and shared access also require treatment appropriate to their actual use.
IGA governs identities and their associated rights, while Access Management enforces authentication policies. Secrets management and PAM solutions intervene where the accounts and operations concerned require additional controls.
IAM mechanisms
- IdP and Access Management.
- MFA.
- Federation.
- Authentication policies.
- Exception management.
- Secrets vaults.
- Secrets rotation according to applicable needs and rules.
- Logging of sensitive changes.
Possible evidence
- Authentication journey inventory.
- Enforced MFA policies.
- Coverage of the remote access concerned.
- Authorised and justified exceptions.
- Policy change history.
- Rotation records for the secrets concerned.
- Typical responsibilities
- Access Management lead, security, application owners and secrets operations.
- Possible indicator
- Proportion of identified remote access journeys effectively covered by the intended MFA.
Nature and limitations of the mappings
This measure must not be presented as explicitly requiring MFA for every application, every connection and irrespective of context.
Technical detail in the context of France’s ReCyF.
Access rights and recertificationReCyF v2.510.C.1 to 10.C.4CyFun 2025 · BasicPR.AA-05.1 to PR.AA-05.3ISO 27001:2022A.5.15, A.5.18, A.8.3, A.5.3 as applicable
Grant, review and remove legitimate access rights
- Problem addressed
- Access rights accumulate as staff change roles. Application owners do not always have a clear view of assigned permissions, and review campaigns may conclude without effective correction.
- Intended outcome
- Keep entitlements aligned with actual need, document decisions and check their implementation.
ReCyF — working version 2.5
10.C.1-EI/EE
Rights assigned to authenticated users and automated processes.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.C.2-EI/EE
Limitation of rights to the resources required.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.C.3-EI/EE
Rights granted only to users and processes with a justified need for the resource.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.C.4-EI/EE
Access rights reviews at least annually, with correction of anomalies.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-05.1 — Basic
Define, manage, enforce and review permissions, access rights and authorisations.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.2 — Basic
Determine who needs access to critical information and technologies.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.3 — Basic
Limit rights and privileges to those needed to perform tasks.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.15
Access control.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.5.18
Access rights.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.3
Information access restriction.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.5.3
Segregation of duties, where relevant to the control being examined.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
Entitlement governance requires a business decision to be linked to a right actually present in the system. An approved request, role rule or recertification campaign is not sufficient if technical permissions do not align with the expected outcome. The control must cover the legitimacy of the right, its assignment, any exceptions and its removal.
Role models allow some decisions to be standardised at scale. They must nevertheless remain appropriate to the organisation and can be supplemented by fine-grained authorisation mechanisms where decisions depend on the resource, action or context.
IAM mechanisms
- Entitlement catalogue.
- Resource owners.
- Business and technical roles.
- Assignment rules.
- Requests and approvals.
- Recertification campaigns.
- Exception management.
- Revocation.
- Checks for discrepancies between intended and effective rights.
Possible evidence
- Access rights matrix.
- Owner approvals.
- Request history.
- Recertification decisions.
- Exception list.
- Completed corrections.
- Revocation log.
- Typical responsibilities
- Business owners, application owners, IAM leads and access rights operations.
- Possible indicator
- Proportion of revocation decisions actually executed and verified in target systems.
Nature and limitations of the mappings
Entitlement governance requires a business decision to be linked to a right actually present in the system. An approved request, role rule or recertification campaign is not sufficient if technical permissions do not align with the expected outcome. The control must cover the legitimacy of the right, its assignment, any exceptions and its removal.
Technical detail in the context of France’s ReCyF.
Shared accountsReCyF v2.510.A.2, 10.A.3, 10.B.3, 10.B.4, 10.B.6, 10.B.7-EECyFun 2025 · BasicPR.AA-01.1, PR.PS-04.1 — indirect linksISO 27001:2022A.5.16, A.5.17, A.8.15
Control shared accounts and preserve accountability
- Problem addressed
- Some legacy systems or operational constraints lead to the use of shared accounts. Without appropriate controls, it becomes difficult to determine who used an account, when and for which operation.
- Intended outcome
- Limit shared use, justify exceptions and retain usable attribution of the access concerned.
ReCyF — working version 2.5
10.A.2-EI/EE
Use of individual accounts restricted to their holders.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.A.3-EI/EE
Compensating measures and traceability where constraints prevent the use of individual accounts.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.3-EI/EE
Renewal of a shared account's secret element after removal of a user of that account.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.4-EI/EE
Protection of knowledge of secrets.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.6-EI/EE
Exception for secrets that cannot be changed, with an additional traceability requirement for EE in the specified case.
Thematic mapping · Identifier and applicability verified in the official document
This exception requires appropriate access control and reduction of the risk associated with the fixed secret; additional traceability falls under 10.B.7-EE.
Version de travail 2.5 du 17 mars 202610.B.7-EE
Exception for secrets that cannot be changed, with an additional traceability requirement for EE in the specified case.
Thematic mapping · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Management of identities and authentication information.
Indirect thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025PR.PS-04.1 — Basic
Maintenance, documentation and monitoring of logs.
Indirect thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Identity management.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.5.17
Authentication information.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.15
Logging.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
Shared account traceability is not simply a matter of retaining technical logs. It requires an understanding of the conditions in which the account was used and the ability to link its use to a person or authorised operation. Where individual accounts are not possible, the exception must therefore be documented, compensating measures defined and their continued operation verified.
Secrets management, session control and operational procedures can contribute to this control. None of these mechanisms should be presented as blanket permission to share accounts without justification.
IAM mechanisms
- Shared account inventory.
- Justification of exceptions.
- Designation of responsible owners.
- Secrets management.
- Rotation when a relevant user's access is revoked.
- Access control.
- Usage traceability.
- Exception review.
Possible evidence
- Shared account register.
- Technical or operational justification.
- List of authorised users.
- Rotation records.
- Relevant logs.
- Periodic check results.
- Decisions to retain or remove exceptions.
- Typical responsibilities
- System owner, security lead, PAM or secrets lead, operations.
- Possible indicator
- Proportion of identified shared accounts with a justified exception and documented traceability arrangements.
Nature and limitations of the mappings
These measures provide thematic points of reference. They must not be presented as a verbatim transposition of the shared account exceptions provided for by ReCyF.
Thematic mappings, to be assessed according to the scope and selected controls.
Technical detail in the context of France’s ReCyF.
Directories and privilegesReCyF v2.511.A.1, 11.A.3, 11.A.4-EE, 11.B.1, 11.B.2-EE, 11.B.6-EECyFun 2025 · BasicPR.AA-05.1, PR.AA-05.4, ID.AM-08.2ISO 27001:2022A.8.2, A.8.9, A.8.15
Secure directories and administration paths
- Problem addressed
- An organisation has IAM governance, but some groups, delegations, administrative accounts and legacy mechanisms in its directories still enable excessive access or privilege escalation.
- Intended outcome
- Connect IAM governance with technical directory security and control of administrative rights.
ReCyF — working version 2.5
11.A.1-EI/EE
Separation of administrative accounts and their use.
Thematic mapping · Identifier and applicability verified in the official document
Administration is performed exclusively through administrative accounts, which are themselves reserved exclusively for these actions.
Version de travail 2.5 du 17 mars 202611.A.3-EI/EE
Application of identity management rules to administrative accounts.
Thematic mapping · Identifier and applicability verified in the official document
The rules concern identities and access for administrative accounts.
Version de travail 2.5 du 17 mars 202611.A.4-EE
Use of administrative accounts limited to the intended resources and administrative operations.
Thematic mapping · Identifier and applicability verified in the official document
Connection to managed resources to administer them, or to an administration resource.
Version de travail 2.5 du 17 mars 202611.B.1-EI/EE
Application of security patches to the directories concerned.
Thematic mapping · Identifier and applicability verified in the official document
Patches must be applied without undue delay.
Version de travail 2.5 du 17 mars 202611.B.2-EE
Identification of the resources forming each directory's trust core.
Thematic mapping · Identifier and applicability verified in the official document
The trust core comprises the directory and the resources that can host it or take control of it.
Version de travail 2.5 du 17 mars 202611.B.6-EE
Annual directory configuration review.
Thematic mapping · Identifier and applicability verified in the official document
The review targets unnecessary or anomalous elements; an automated tool is recommended, not mandated by this line.
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-05.1 — Basic
Management and review of access rights.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025PR.AA-05.4 — Basic
No administrative privileges for routine tasks.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025ID.AM-08.2 — Basic
Installation of security patches and updates on the critical systems and components concerned.
Thematic mapping · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.8.2
Privileged access rights.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.9
Configuration management.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.15
Logging.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
Directory security does not automatically follow from entitlement governance. IGA can control the assignment of groups and rights, but protecting Active Directory or LDAP also requires analysis of delegations, sensitive accounts, configurations and paths leading to critical resources. Corrections must be prioritised according to risk rather than limited to an inventory of administrative accounts.
PAM addresses certain privileged uses, but reducing standing privileges and securing the trust core also require architectural, configuration and operational decisions. A bastion host alone does not eliminate attack paths within the directory.
IAM mechanisms
- Administrative account review.
- Sensitive group analysis.
- Separation of administrative activities.
- Delegation analysis.
- Privilege reduction.
- Attack path checks.
- Directory configuration review.
- Patch management.
- Logging of critical changes.
Possible evidence
- Privileged account and group inventory.
- Justification of sensitive rights.
- Attack path mapping.
- Remediation history.
- Configuration review reports.
- Patch tracking.
- Privileged change logs.
- Typical responsibilities
- Directory team, IAM architect, identity security, PAM lead and operations.
- Possible indicator
- Number of critical attack paths identified and subsequently eliminated or controlled within a documented scope.
Nature and limitations of the mappings
These references are neither an exhaustive description of Active Directory hardening nor equivalent to the French requirements for the trust core.
Technical detail in the context of France’s ReCyF.
Machine identities and certificatesReCyF v2.510.A.1, 10.A.5, 10.B.1, 10.B.2CyFun 2025 · BasicPR.AA-01.1ISO 27001:2022A.5.16, A.8.24
Govern machine identities and their trust mechanisms
- Problem addressed
- An organisation knows its staff accounts but has insufficient control over the identities of applications, devices and automated processes. Some certificates, secrets or technical accounts persist without an identified owner or documented lifecycle.
- Intended outcome
- Link technical identities to their uses and control associated cryptographic mechanisms where these are used.
ReCyF — working version 2.5
10.A.1-EI/EE
Individual identification of users and automated processes accessing resources.
Operational contribution · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.A.5-EI/EE
Deactivation of accounts no longer required.
Operational contribution · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.1-EI/EE
Authentication mechanisms for users and automated processes.
Operational contribution · Identifier and applicability verified in the official document
Version de travail 2.5 du 17 mars 202610.B.2-EI/EE
Changing default secret elements.
Operational contribution · Identifier and applicability verified in the official document
The text also requires checking with the supplier that the means and rights needed to make the change are available.
Version de travail 2.5 du 17 mars 2026
CyFun 2025 — Basic
PR.AA-01.1 — Basic
Management of identities and authentication information for users, services and devices.
Operational contribution · Documentary verification to be confirmed
CyFun 2025 — Basic, 1er octobre 2025
ISO/IEC 27001:2022
A.5.16
Identity management.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022A.8.24
Use of cryptography.
Thematic mapping · Documentary verification to be confirmed
ISO/IEC 27001:2022
Annex A controls must be examined in light of the risk assessment, the ISMS scope and the Statement of Applicability (SoA).
European references — Article 21(2)
NIS2 Directive
Article 21(2)(h)
cryptography and, where appropriate, encryption.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(i)
human resources security, access control and asset management.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555Article 21(2)(j)
MFA or continuous authentication where appropriate.
Operational contribution · Documentary verification to be confirmed
Directive (UE) 2022/2555
Ariovis analysis
A machine identity is not simply a service account. It may be represented by a certificate, key, token, application account or a combination of mechanisms. The organisation must distinguish the legitimacy of this identity, the resources it can reach and the technical means used to authenticate it.
IAM can govern the owners, uses and entitlements of these identities. PKI manages certificates and the corresponding cryptographic mechanisms. Controlling risk requires coordination between these responsibilities, particularly when an application is retired, a certificate expires or a secret must be revoked.
IAM mechanisms
- Machine identity inventory.
- Identification of owners.
- Service account management.
- Technical identity lifecycle.
- Inventory of relevant certificates.
- Granting and removal of access rights.
- Certificate issuance, renewal and revocation through appropriate systems.
- Control of associated secrets and keys.
Possible evidence
- Non-human identity inventory.
- Documented owner and purpose.
- References to associated accounts or certificates.
- Validity and renewal dates.
- Revocation history.
- Access rights review results.
- Handling of identities no longer required.
- Typical responsibilities
- Application owners, IAM team, PKI team, operations and security.
- Possible indicator
- Proportion of critical technical identities with an owner and a documented renewal or revocation mechanism.
Nature and limitations of the mappings
None of the cited references should be presented as systematically requiring all organisations to deploy a complete PKI.
Certificates are one possible technical mechanism for certain uses. Their management depends on the authentication, trust and cryptographic needs concerned.
Technical detail in the context of France’s ReCyF.
From a security measure to evidence that it works
A written policy describes what should be done. Operational evidence makes it possible to verify what was actually decided, executed and checked. For IAM, this distinction is essential: creating a revocation workflow does not demonstrate that all expected revocations have been completed, just as launching a recertification campaign does not demonstrate that the agreed corrections have been applied.
Organisations benefit from structuring their evidence around a few common elements: the scope concerned, the rule applied, the person responsible for the decision, the operation performed and its outcome. This method can support several assessment processes, provided the evidence pack is adapted to the requirements and assessment arrangements that actually apply.
Anatomy of IAM evidence
- Scope
- Entity, application, population, resource or set of accounts concerned.
- Decision
- Applicable rule, request, approval or triggering event.
- Execution
- Operation performed in the target system, with its status and date.
- Exception
- Discrepancy encountered, justification, owner and planned correction.
- Verification
- Check result, retained records and ability to reconstruct the operation.
Technically available evidence is not automatically sufficient for an audit, CyFun verification or ISO 27001 certification. Its relevance depends on the scope, applicable requirements and assessment method.
A group IAM strategy that respects local realities
Ariovis supports international organisations in defining identity governance suited to their processes and architecture. This work can begin with an assessment of sources, entitlements and responsibilities, then continue with the development of a master plan, solution integration and implementation of operational controls. The aim is to produce a realistic roadmap that improves security without imposing unnecessary changes on subsidiaries.
Support can bring together central and local teams, from defining IAM principles through application connections, access reviews and operations. Regulatory requirements inform scoping, but technical decisions remain guided by risks, usage and the organisation’s actual capabilities.
IAM strategy and Zero Trust
Build a master plan, a governance model and a gradual integration roadmap.
Identity governance
Harmonise lifecycles, entitlements, approval rules and traceability.
Access Management and CIAM
Secure federation, authentication and access policies across heterogeneous systems.
PAM
Reduce and control privileges and sensitive operations, taking actual usage into account.
Official sources
This analysis is based on the European NIS2 Directive and explanations published by the competent authorities. It distinguishes European principles, national specificities and IAM organisational recommendations. Rules on jurisdiction and scope require verification tailored to each entity.
- NIS2 Directive (French)
- Article 2 — Scope.
- Article 3 — Essential and important entities.
- Article 4 — Relationship with sector-specific legal acts.
- Article 21 — Risk-management measures.
- Article 23 — Incident reporting.
- Article 26 — Jurisdiction and territorial scope.
- Article 27 — Registry of certain entities.
- ANSSI, multinational NIS2 FAQ (French)
This source distinguishes, in particular, the concept of an entity, the different categories of jurisdiction and the situation of groups.
The FAQ is informative and does not replace applicable legislation.
- European Commission, NIS2 FAQ
- France, ANSSI (French)
- France, Resilience Bill (French)
- Belgium, CCB (French)
- Belgium, Safeonweb@Work (French)
Build a shared IAM foundation without erasing local responsibilities
An international organisation does not necessarily need to multiply its identity platforms to address differences between jurisdictions. It must first clarify responsibilities, the processes that can be shared and the controls requiring local adaptations. Ariovis supports groups in defining this governance, building a target architecture and progressively implementing identity and access processes while retaining evidence that the entities concerned can use.
Explore our IAM master-planning method