One figure from the first NIS2 audit feedback in France deserves attention: in 74% of the first compliance missions conducted by the competent national authorities in the first half of 2026, identity and access management (IAM) generated at least one observation. It is the control category most frequently flagged, ahead of vulnerability management and business continuity. This is no accident. It reflects a structural gap between how organisations design their security perimeter and what the texts actually require.
In this article, we examine why IAM has become the first line of attack for NIS2 and DORA auditors, which gaps are the most common, and how GRC directors can address them without a full architectural overhaul.
Why IAM sits at the heart of NIS2 and DORA
Article 21 of NIS2 imposes a list of risk management measures that essential and important entities must implement. Two of them relate directly to identity management: "policies and procedures regarding the use of cryptography and, where appropriate, encryption" and "access control and asset management". DORA, in its Article 9, is more precise still: policies for access to information systems must be based on the principle of least privilege and reviewed periodically.
This regulatory framework does not treat IAM as one architectural option among others. It sets it as a verifiable obligation of means. The direct consequence: a NIS2 or DORA auditor may ask to see your access policy, the list of high-privilege accounts, the connection logs for the last six months, and the active supplier accounts. If you cannot produce these items within a few hours, you have a documented compliance problem.
The paradox observed in the first audit missions: many organisations have IAM tools deployed, such as Active Directory, an LDAP directory and sometimes an MFA solution. But they have no documented IAM policy, no periodic rights review process, and no up-to-date inventory of high-privilege accounts. The tooling exists; the governance is missing. This is precisely what auditors look for.
The three gaps auditors find systematically
1. No periodic review of access rights
Rights review is the IAM requirement most systematically absent in audited organisations. NIS2 requires it implicitly through its obligation on "asset management"; DORA RTS Article 9.4 makes it explicit: access rights must be reviewed at regular intervals and on every change of role or scope.
In practice, most organisations carry out ad hoc reviews, after an incident or before an audit, rather than systematically. The problem is not the absence of a review, but the absence of evidence of review. An auditor who asks "show me the last privileged access review campaign, with its results and remediation actions" cannot be satisfied with an oral answer. The only acceptable format is documented evidence, time-stamped and signed by the control owner.
The common mistake is to confuse extracting an Active Directory report with carrying out a rights review. A raw report of accounts and groups is not a review: it is raw data. The review is the analysis by system owners, the decision to revoke or maintain access, and the traceability of that decision.
2. Supplier accounts not revoked
This is statistically the gap most often linked to a formal observation. In organisations that use IT service providers, managed service providers or external consultants, access accounts created during missions are rarely revoked systematically at the end of the contract. Several factors explain this: revocation is not part of the offboarding process, responsibility is not clearly assigned (IT? procurement? CISO?), and dormant accounts do not generate any visible alert.
The regulatory risk is twofold. On the one hand, NIS2 Article 21 requires control of third-party access as an integral part of supply chain risk management. On the other hand, a supplier account that is still active but has not been used for six months is a documented attack vector, and its presence in a post-incident audit creates a direct legal exposure for the security manager.
The operational solution is not necessarily technological: an offboarding procedure that includes access revocation as a formal step, verifiable by the CISO, is enough to address the observation. Governance first, tooling second.
3. Multi-factor authentication not universally applied
The MFA requirement is one of the few NIS2 requirements that technical directors consider "already done". In practice, audits regularly reveal partial scopes: MFA deployed on email and VPN, but absent from access to infrastructure (cloud consoles, administration interfaces, RDP). For DORA, RTS Article 9.3 is explicit: strong authentication is required for all access to critical systems, including maintenance access.
The definition of "critical systems" is broader than most IT departments anticipate. It includes log management systems (SIEM, log management), backup platforms, network monitoring tools, and the administration interfaces of the security solutions themselves. An attacker who compromises your backup management console through an admin account without MFA can wipe all your backups without triggering any alert: this is exactly the scenario DORA seeks to prevent.
What auditors ask for first
The list of the five first documentary requests in a NIS2/DORA audit focused on IAM: the formalised and dated access policy, the register of high-privilege accounts with assigned owners, the evidence of the last rights review campaign, the supplier offboarding process with revocation tickets from the last 12 months, and the list of critical systems with MFA coverage per system.
What stands out in this scope is that none of these items is technically complex to produce. A standard enterprise IAM tool generates five of them within a few hours. What is missing, in the vast majority of cases, is the decision to organise them and the maintenance routine that ensures this evidence is always available, not only on the day of the audit.
How to address IAM compliance without rebuilding everything
IAM compliance does not require deploying a six-figure IGA (Identity Governance and Administration) solution. Most auditable requirements can be covered with existing tools, provided three governance elements are added.
First element: a formalised access policy, one page, validated by the CISO and management, which sets out the principles of least privilege, the review frequency (quarterly for high privileges, half-yearly for standard access), and the offboarding process. Second element: a calendar of review campaigns, with a named owner per system and a documented output format. Third element: a register of high-privilege accounts and supplier accounts, kept in any tool (including a structured spreadsheet), with one entry per account, an owner, and a date of last review.
These three elements cover 80% of the IAM observations documented in the first NIS2 audits. They require no additional budget, only organisation and operational discipline.
Presidio automates these three processes natively: scheduled review campaigns with alerts to owners, a register of high-privilege accounts synchronised with the directory, and logging of remediation actions. To assess your current IAM coverage, contact our team: we offer a targeted 45-minute diagnostic. Also read: NIS2: the 5 pitfalls of 24-hour incident notification.
Conclusion
IAM has become the first ground of NIS2/DORA audits not because it is the most technical of the controls, but because it is the most legible for an auditor: the evidence is either available or missing. There is no grey area. The policy exists or it does not; the review is documented or it is not; the supplier account is revoked or it is still active.
Three takeaways for your GRC programme: document your access policy before any other IAM project; make supplier account revocation a formal and verifiable step of every offboarding; map your MFA coverage per critical system before your next audit. And in your context, how long would it take you today to produce the list of active accounts for your suppliers over the past twelve months?