A European Identity Assurance Checklist for the AI Act, Dora and NIS2

The EU AI Act is changing how organisations govern artificial intelligence. Its risk-based model assigns obligations according to the organisation’s role and the AI system’s classification. For high-risk systems, the framework covers risk management, technical documentation, logging, human oversight, accuracy, resilience and cybersecurity.

The Act entered into force on 1 August 2024 and is applying in phases. Prohibited practices and AI literacy rules have applied since February 2025, while obligations for general-purpose AI models have applied since August 2025. The timetable for high-risk systems was revised through the 2026 political agreement on the AI Omnibus, according to the European Commission’s AI Act implementation overview.

For security leaders, the key question is: who can configure an AI system, approve its actions, access its data, invoke its APIs and suspend it when required?

These responsibilities fall within IAM and PAM and overlap with DORA and NIS2 requirements for access control, accountability, supplier oversight, incident response and resilience. A common control model can support all three regimes, subject to separate applicability and risk assessments.

Where the three regimes meet

1. DORA applies to financial entities and has covered ICT risk, resilience, incident management and third-party oversight since 17 January 2025. Its supporting technical standards contain detailed provisions for identity management, access control and logging, as set out in the Digital Operational Resilience Act.
2. NIS2 covers 18 critical sectors through national legislation. It introduces management accountability and requires appropriate technical, operational and organisational measures, including access control, asset management, business continuity, supply-chain security, incident handling and multifactor or continuous authentication. Member States had until 17 October 2024 to transpose the Directive, according to the European Commission’s NIS2 overview.
3. The AI Act applies according to the type of AI system and the organisation’s role in placing, providing or using it. For covered high-risk systems, traceability, human oversight and cybersecurity create clear identity questions around administrators, deployers, data access and automated actions, as described in the European Commission’s AI Act regulatory framework.

The operational overlap includes clear ownership, restricted access, activity that can be attributed to a human or non-human identity, tested recovery, supplier control and evidence that controls work.

The AI Act extends this assurance model to AI systems that access data, invoke tools or take actions. The following checklist applies the same control discipline across human, machine and AI identities.

ENISA’s NIS2 Technical Implementation Guidance supports the use of documented identity processes, access registers, approval records, periodic reviews and technical evidence. Its scope is limited to the digital infrastructure, ICT service management and digital-provider entities covered by Commission Implementing Regulation 2024/2690.

The assurance principle

A control is assured when it has:

1. a named owner;
2. defined scope and policy;
3. reliable evidence;
4. a managed exception process;
5. a recent test result.

IAM and PAM assurance depends on how controls operate across people, suppliers, workloads, APIs, service accounts and AI agents.

A European IAM and PAM assurance checklist

1. Governance and ownership

Assign executive ownership for identity risk. Define responsibility across IAM, IGA, PAM, directories, authentication, secrets, machine identities and AI systems.

Record regulatory applicability, AI Act role classification, control ownership, evidence ownership, open exceptions and accepted residual risk.

Evidence: approved policies, RACI records, risk registers, exception approvals and management reports.

2. Identity and entitlement inventory

Maintain a reconciled inventory of every identity with access to important services.

Include employees, contractors, suppliers, privileged accounts, service accounts, workloads, API clients, application identities and action-taking AI agents. Record the owner, purpose, scope, privilege level, authentication method and review date.

Evidence: identity inventories, entitlement catalogues, ownership records, dormant-account reports and mappings to business services.

3. Lifecycle governance and access reviews

Connect access changes to authoritative business events. Automate joiner, mover and leaver processes where possible. Give temporary and supplier access an expiry date.

Access reviews need context: role, current use, risk, conflicting access and the service affected. A completed review should also prove that rejected access was removed.

Evidence: requests, approvals, provisioning logs, certification results, revocation records and segregation-of-duties rules.

4. Privileged access

Limit privilege by task, duration and system. Reduce standing administrator rights. Attribute every privileged action to a person or governed non-human identity.

Test credential rotation, just-in-time elevation, emergency access and supplier administration. Record or monitor high-risk sessions according to risk.

Evidence: privileged-account inventories, elevation records, approval workflows, rotation logs, session records and break-glass tests.

5. Authentication and contextual access

Measure authentication coverage by risk category: privileged, remote, supplier, workforce and critical-system access.

Track phishing-resistant methods separately from general MFA. Test enrolment, recovery, fallback and help-desk procedures. Device posture, location, session risk and access context should influence higher-risk decisions.

Evidence: MFA and passkey coverage, conditional-access policies, device reports, exception registers and recovery tests.

6. Logging and traceability

Investigators should be able to establish who requested access, who approved it, what identity used it and what action followed.

Correlate identity, PAM, application, API and infrastructure records. Protect logs from alteration, synchronise timestamps and define retention periods. AI-agent activity requires attribution to an owner, credential and approved purpose.

Evidence: audit trails, approval histories, policy-change logs, API records, AI activity logs and tested alert rules.

7. Supplier and cloud assurance

Record supplier administrators, subcontractors, service locations and access paths. Contracts should cover audit rights, incident cooperation, termination, data return and exit support.

Test whether supplier access can be restricted quickly and whether logs can be obtained during an investigation.

Evidence: supplier registers, criticality assessments, contract clauses, access reports, incident procedures and exit-test results.

8. Identity-service resilience

Identity providers, directories, PAM vaults, certificate services and secrets platforms are dependencies for wider business services.

Define recovery objectives, configuration backups, failover procedures and independent emergency access. Test restoration of policies, credentials and secrets.

Evidence: dependency records, recovery objectives, backup results, recovery exercises and break-glass test reports.

9. Identity-led incident containment

Identity teams need defined first-hour actions. Test account disabling, session and token revocation, privilege suspension, supplier-access removal and credential rotation.

Measure how long each action takes and record technical failures. Include IAM and PAM teams in incident exercises and reporting workflows.

Evidence: containment playbooks, exercise results, revocation records, rotation reports and time-to-containment metrics.

10. AI and non-human identities

Treat every action-taking AI agent as a governed non-human identity.

Record its business owner, technical owner, approved purpose, permitted data, available tools, API scope, credential type and maximum permissions. Define when human approval is required, who can suspend the agent and how its actions can be reversed.

Evidence: AI-system inventories, agent ownership records, permission scopes, approval logs, activity records, suspension tests and rollback procedures.

This is a practical identity-security interpretation of the AI Act. The Act does not prescribe a PAM platform, short-lived agent credentials or one specific agent-access design. These controls support its requirements for oversight, traceability and cybersecurity.

The minimum evidence pack

Maintain a standing evidence pack containing:

1. Scope and ownership
2. Identity and entitlement records
3. Authentication and privileged-access evidence
4. Supplier and resilience evidence
5. Incident and AI-agent records
6. Exceptions and remediation

Evidence should identify its source system, custodian, collection date and applicable control. This makes its age and reliability visible.

A 90-day European identity assurance programme

Days 1–30: define scope and ownership

Confirm AI Act, DORA and national NIS2 applicability. Identify critical services and identity dependencies. Assign control and evidence owners. Inventory human, supplier, privileged, machine and AI identities. Map important technology and cloud providers.

Days 31–60: test the highest-risk controls

Review standing privileges and supplier administration. Test leaver removal, temporary access expiry, MFA recovery, session revocation, credential rotation and emergency access. Exercise identity-service recovery. Review AI-agent permissions, human approvals, logging and suspension controls.

Days 61–90: remediate and document

Remove unnecessary access. Resolve high-risk orphaned and dormant accounts. Improve lifecycle automation and expiry controls. Correct authentication, recovery and supplier-access gaps. Run an identity-led incident exercise. Complete the evidence pack and introduce management metrics.

Useful measures include ownership coverage, the number of standing privileged accounts, overdue access reviews, supplier accounts without expiry, machine identities without rotation policies and AI agents without approved data or tool scopes.

The one-day evidence test

European organisations should be able to answer five questions for every important identity control:

• Who owns it?
• Who has access?
• Who approved that access?
• What happened when it was used?
• When was the control last tested?

A sixth question tests operational readiness: could the organisation produce the supporting evidence within one working day?

The AI Act, DORA and NIS2 apply to different organisations, systems and risks. A common IAM and PAM control set can reduce duplicated assurance work while giving security leaders a consistent view of access across human, machine and AI identities.