Article 21 of NIS2 adopts a principles-based approach. It requires organisations to implement appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks affecting their systems and data.
As such, Article 21 establishes a standard of organisational diligence, but not a catalogue of technical requirements. The result is a legal framework that shifts regulatory attention towards governance.
This is also true for the access control requirement. Although the Directive says “human resources security, access control policies”, this shouldn’t be limited just to human identities. Read in conjunction with the other requirements, “access control policies” must extend to non-human identities as well, including API keys, service accounts, and increasingly AI agents.
The first step toward a comprehensive identity and access risk management governance is inventorying those identities, both human and non-human, that nobody knew before.
Key insights
- NIS2 Article 21 sets a standard of organisational diligence for access control, and that standard covers API keys, service accounts and AI agents alongside employee accounts.
- Scope the critical services first, since that shows where a compromised identity would do the most operational damage.
- API keys and service accounts created for a single integration can keep working for years with no expiry and no review, often after their creator has left.
- Contributors to a 2026 NIS2 access management report by Passwork argue that non-human identity can no longer be treated as an edge case and belongs in the core identity estate.
- Each consequential agent should hold its own identity and least-privileged access, so logs show which agent acted and there is a specific credential to disable.
- Accountability for every non-human identity sits with a named system or service owner; software cannot answer for its own permissions.
Look around the critical service
Although the obvious prioritized action might be to inventory all your identities before deciding how to protect them, cybersecurity professionals in the latest NIS2 access management report by Passwork, a European password and secrets manager, caution against scoping your critical services first.
Jane Frankland MBE, Founder and CEO at KnewStart, notes that businesses must first understand their critical services, their business outcomes, and how to “keep your company operating when something happens.” According to Frankland, scoping “tells you where an identity compromise could have the greatest impact.”
Dr. Yiannis Pavlosoglou, Deputy Governor at Greece’s National Cybersecurity Authority, recommends to identify the accounts connected to those services, including identities that do not belong to employees, and examine the access they hold.
Begin with the places that will most likely hold these identities: think cloud identity platforms, secrets stores, CI/CD pipelines, source repositories, configuration files, and SaaS integrations. Service accounts are trickier to trace, particularly if the person who created them is no longer with the company.
For each identity, find out why it was created, what still depends on it, and what access it has. If nobody knows what would stop working if a broadly privileged credential were revoked, that is a problem in itself.
The old API key may be the bigger problem today
An exposed API key can sit in a production environment for months without attracting much attention. A developer may create one for an integration, add it to the system, and move on.
Unless something forces that key to expire or brings it back up for review, it can keep working long after anyone has thought about why it was created.
An API key inventory needs to uncover that history. Look at when the key was created and when it was last used. Find the workload or integration that depends on it. If the key still needs to exist, its permissions should match what that workload needs now.
The same exercise often uncovers service accounts with similar histories. They were created for a reason, but nobody came back later to check whether the reason still existed.
Give the agent its own identity
Agents create another problem when several of them operate through a shared account. The logs show what the account did, but not which agent initiated the action.
Jane Frankland argues that consequential agents should have their own accounts and least-privileged permissions. “I don’t think non-human identity can be treated as an edge case anymore. It’s got to become part of the core identity estate.”
Giving an agent its own identity makes its permissions visible, and gives you something specific to disable if the agent starts behaving unexpectedly.
The permissions need to reflect what the agent is supposed to do. An agent reading information for an internal task does not need the same authority as one allowed to change a production configuration or initiate transactions.
There is also a question that does not arise in quite the same way with an API key: which actions can the agent take without asking a person?
You need to decide on the boundary when granting permissions. Leaving it until an agent takes an unexpected action means the decision has already been made by whatever access it was given.
Credentials should not live forever
Long-lived credentials leave a lot riding on somebody remembering to rotate or revoke them.
Where the system supports it, machine identities can use credentials that expire automatically. A workload gets access for the period it needs it, then it must obtain another credential instead of carrying the same static secret indefinitely.
This is particularly relevant to AI agents. The access processes used for employees were built around human activity and human review cycles, but agents can operate much faster and may create or use credentials while carrying out a task. A quarterly review is a poor place to discover that an agent created a credential months earlier and nobody has looked at it since.
Employees can spin up agents for low-stakes experiments and then stop thinking about them. The forgotten agent then continues to consume resources or retain access after the experiment has ended.
Automatic expiry also limits how long a forgotten or leaked credential can remain useful.
Somebody still owns the access
Software cannot answer for its own permissions. The person or team responsible for the system should be able to explain why a non-human identity exists and decide whether it still needs its access.
That owner will not always be the developer who originally created the API key or service account. Service or system owners should be held accountable for the permissions APIs have, since they are the ones who understand all the dependencies and how the service functions.
AI enhances the need for that responsibility and accountability. Whoever deploys the agent or manages the system still needs to account for the access granted to it.
Sometimes, AI agents are granted more access and authority than required because we lack the understanding of how businesses operate. This is why we need a comprehensive understanding not only of the identities in our ecosystem but also of the systems they touch and the impact those identities have on availability and integrity.
Bios
Jane Frankland MBE is an author, strategist, and leading authority on cyber survivability. Her work explores how organisations can reduce the impact of cyberattacks, preserve choice under pressure, and recover better. With nearly three decades in cybersecurity, Jane founded an early penetration testing company and later became a Managing Director at Accenture. Today, she works with leaders and global organisations, challenging conventional thinking about cybersecurity through a focus on leadership, culture, governance, defence and collaboration. Jane was awarded an MBE for services to women in cybersecurity and has enabled more than 542 scholarships for women in cybersecurity since 2018. Find her on LinkedIn or at jane-frankland.com.
Dr. Yiannis Pavlosoglou is the Operational Deputy Director of the Greek National Cybersecurity Authority; he is a senior cybersecurity executive with 20 years of experience in risk assessment and management, as well as information assurance. He has served as the UK Chief Information Security Officer at UBS. He was a member of the Board of Directors of ISC2, serving as its Chair in 2023. He holds a PhD in Engineering for Secure Protocol Design and a Bachelor of Engineering in Computer Systems Engineering from the University of Warwick in the UK.
Author bio
Tassos is a seasoned cybersecurity expert who can strategize, manage, and deliver. He brings decades of experience in people-centric security and awareness to the table. Throughout his career, Tassos has championed positive security and innovative awareness methods, challenging the status quo with fresh perspectives grounded in people’s needs and relationships.
Currently, he is a senior cybersecurity marketing expert at Bora Design and a member of the ISC2 Hellenic Chapter.
