Non-human identities: the systemic blind spot in your NIS2 and DORA programmes

For every human identity, there are now 45 non-human identities in a corporate infrastructure. API tokens, service accounts, AI agents: your NIS2 and DORA programmes structurally ignore them.

Monitoring screens displaying machine connection flows

When your GRC team talks about "identity and access management", it thinks of employees: Active Directory accounts, VPN access, half-yearly rights reviews. This is the right answer to the wrong question. In 2026, human identities no longer represent more than a minority of the active identities in a corporate infrastructure. An analysis of 350 organisations published by CyberArk in 2025 shows that, for each human identity, there are now an average of 45 non-human identities (NHIs): service accounts, API tokens, SSH keys, certificates, AI agents, CI/CD pipelines, SaaS connectors. These identities are not subject to any quarterly review. They do not go on holiday. And when they are compromised, they stay active until someone revokes them, which can take months.

The regulatory context: NIS2, DORA and the silence on NHIs

NIS2 (Article 21, paragraph 2, point i) requires access control and identity management as mandatory security measures. DORA (Article 9) requires the management of privileged access and the monitoring of critical rights. Both texts are clear on the need for rigorous access control. Neither explicitly defines the scope of "identities" to be covered.

In practice, 83% of CISOs who responded to the Gartner Identity Security 2025 survey say that their IAM programme focuses mainly on human identities. Their lifecycle management policies apply to employees: rarely to service accounts, and almost never to API tokens generated by SaaS tools or automated pipelines.

The result: during the first NIS2 checks conducted in France and Germany in the first half of 2026, several entities received observations concerning service accounts with high privileges active for more than 24 months, without documented review. These observations did not lead to immediate penalties, but they appear in audit reports as "insufficient controls", which, in a later incident, can tip the assessment of fault.

The three attack vectors your NHI programmes do not cover

Long-lived tokens without rotation. API access tokens for SaaS integrations (Salesforce, Jira, AWS, GitHub) are often created once, stored in a configuration file, and never renewed. According to a GitGuardian study covering 3.4 million public GitHub commits in 2025, 12% contained at least one active secret (token, API key, credential) that had not been revoked at the time of detection. The median lifespan of these exposed tokens exceeded 14 months.

Orphaned service accounts. Every supplier migration, merger or rotation leaves behind active service accounts whose organisational owner no longer exists. An audit of a sample of 120 mid-market European organisations in 2024 found an average of 34 active service accounts whose owner had left the organisation, with rights over critical systems. These accounts are not reviewed because they do not appear in the HR offboarding process.

AI agents with persistent access. This is the emerging vector that is redefining the attack surface in 2026-2027. AI agents deployed to automate GRC processes or anomaly detection operate with their own identities, often service accounts with high privileges over the systems they monitor. The question is not whether these agents are reliable: it is what happens if the API key that gives them access to your HR system or your GDPR records of processing is compromised by a third party.

Four measures that do not require re-architecting your IAM

Inventory before securing. You cannot manage what you cannot see. The NHI inventory is the prerequisite for any measure. It must cover: all Active Directory and Entra ID service accounts, all active API tokens, all certificates with their expiry dates, and all CI/CD pipelines with their associated rights. Secrets vaults (CyberArk, HashiCorp Vault, AWS Secrets Manager) make it possible to centralise this inventory.

Apply least privilege to non-human accounts. A CI/CD pipeline does not need administrative rights over your production database. A monitoring service account does not need write rights. The review of NHI rights follows the same principles as the review of human rights: it is simply carried out less often. An annual NHI scope audit is a start; a quarterly review cycle aligned with your DORA programme is the target.

Set up automatic secret rotation. Tokens and passwords for service accounts should not have an indefinite lifespan. Automatic rotation, at most 90 days for privileged access and 30 days for critical systems, is a good practice that NIS2 can be read as implicitly requiring under access management. Modern vaults make it possible to automate this rotation without manual intervention.

Integrate NHIs into your supplier offboarding processes. When a supplier or a SaaS tool leaves your scope, the offboarding procedure must explicitly cover the revocation of the associated tokens and service accounts. This is a process change, not an architectural one, but it requires IT, security and procurement teams to speak the same language.

How to assess your current exposure

An NHI diagnostic can be started in four hours of structured interviews with your IT and security teams. Presidio includes non-human identity mapping in its NIS2/DORA assessment module, with automated risk prioritisation by exposure level and a sequenced remediation plan. Request a free diagnostic →

Also read: IAM and access control: NIS2 and DORA audit priorities, DORA and ICT concentration risks.

Related engagement: Security tooling integration

Request a call