NIS2 access management: What five experts would fix first

From policy to practice: who had access to what, with whose approval, for how long, and can you prove it?

Five cybersecurity leaders on the access controls that are hardest to operationalize, and the evidence organizations need to demonstrate that they work.

Executive summary

NIS2 has changed what organizations need to demonstrate about access management. Putting cybersecurity controls in place is no longer enough. Organizations also need evidence that those controls work, who is responsible for them, and what happened when someone (or something) accessed a critical system. For management bodies, the responsibility of proving that access management controls are in place and work can now carry personal liability.

That evidence also has to cover more than employees. Service accounts, API keys, suppliers, and AI agents can all have access to critical systems. Knowing those identities exist, what they can access, and whether that access is still justified has become part of the same problem.

Five cybersecurity leaders interviewed for this report approached that problem from different directions. They debated on which NIS2 Article 21 requirement is hardest to operationalize and where organizations remain most exposed. In the end, their answers repeatedly returned to the difference between having an access management control (or any other security control) and demonstrating that it works.

Contributors

Gabriel Dinu

Deputy Director, National Cyber Security Directorate of Romania
ENISA Management Board representative

Jane Frankland MBE

CEO and Founder of KnewStart

Ioannis Ntokos

IT Governance Risk & Compliance Expert (former FedEx, PwC, and Randstad)

Dr. Yiannis Pavlosoglou

Vice Governor, National Cybersecurity Authority of Greece

Alex Muntyan

CEO of Passwork

Disclaimer: The four external contributors to this report took part as independent experts. None of them has a commercial relationship with Passwork or endorses its products. Their views are their own and do not represent the positions of their current or former employers.

The test that makes NIS2 real

Access management under NIS2 can be defined by one foundational question: 

The rest of this report applies that question to the people, suppliers, service accounts, API keys, and AI agents that can reach critical systems. It also asks whether the evidence left behind is good enough to show what happened.

Article 21 requires essential and important entities to manage cybersecurity risk through measures that reflect the risks they face. Article 23 sets strict, mandatory incident-reporting rules for essential and important entities experiencing a significant cyber incident. Those requirements apply to both essential and important entities, although the ways those organizations are supervised differ.

Management bodies must approve the cybersecurity risk management measures and oversee their implementation. Each member state must appoint a competent authority to oversee and enforce the directive.

NIS2 puts that responsibility on the management body for a practical reason. However an attacker gets in, stolen or misused credentials tend to appear somewhere along the way. 

• Verizon’s 2026 Data Breach Investigations Report found credential abuse in 39% of the breaches it analyzed, a larger share than any other technique. 
• ENISA’s 2026 Threat Landscape, which analyzed 8,257 incidents recorded across 2025, found that phishing accounted for 77.8% of social engineering activity, most of it aimed at a password or an active session, while vulnerability exploitation was behind six in ten unauthorized-access incidents. Essential entities under NIS2 were the target in 72.9% of the incidents recorded.

A board approving cybersecurity measures without asking how access is controlled is approving a plan with its most exploited weakness left out.

That choice, intentional or not, comes with consequences. For essential entities, infringements of Article 21 and Article 23 can lead to maximum administrative fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher. 

Enforcement is moving, too. The initial deadline was in October 2024, but only very few countries met it. In July 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the European Union for failing to notify measures fully transposing NIS2 into national law.

Article 21 covers a wide range of cybersecurity measures, and the practical challenges differ across them. When asked which is hardest to operationalize, each expert pointed somewhere different. 

• Pavlosoglou highlighted MFA, pointing to legacy systems that cannot support it, technical accounts that break when it is switched on, and the exceptions people start asking for almost immediately.
• For Dinu it is supply chain security, which he sees as difficult both for organizations to implement and for regulators to assess.
• Frankland said that it is assessing whether cybersecurity measures are effective, and while having a control is one thing, proving that it works is a completely different conversation.
• Muntyan focused on access control and credential management, particularly whether an organization can show who had access and what they did.
• Ntokos chose incident handling because so many processes and people become involved once an incident happens.

Compliance with those measures also takes more than technical controls, often depending on the organizational culture and the people using them.

Dinu compares regulation to seatbelt laws. People should wear a seatbelt because it protects them, not just because the law mandates it, and he argues that cybersecurity should work the same way. In practice, too often organizations treat security as a cost until regulation or an incident forces them to act.

Pavlosoglou approaches the culture problem from another direction. Asked about the barriers to compliance, he points to whether organizations are willing to disclose what happened when an incident occurs. 

The CSIRTs network gives national authorities across the EU a way to share information about attacks, making cooperation with authorities part of the response instead of a conversation that starts only when enforcement arrives.

Culture is harder to change than a policy. NIS2 adds another lever by putting responsibility for those cybersecurity measures at the management level.

Liability changed the boardroom conversation

With the management body responsible for approving and overseeing NIS2 implementation, that strengthens the CISO's position—particularly when access-management weaknesses require additional budget or changes elsewhere in the business.

Dinu has seen the effect firsthand. Consultants he spoke with described management showing little interest in cybersecurity presentations until liability came up. Then, he said, "It changed the whole atmosphere in the room." Once board members can be held liable, it becomes much harder to dismiss a security problem as something for the CISO to deal with.

Muntyan sees a similar change from the vendor side. Security might previously have reached the board once a year. In Passwork's conversations with organizations, he now sees C-level executives becoming more involved, where discussions once stayed with IT managers and architects.

Ntokos also sees senior management accountability as a positive change. Once cybersecurity risk becomes a business and financial responsibility, he argues, it’s harder for leadership to leave it entirely with the security team.

Pavlosoglou points to the implementation in Greek law of the NIS2 EU Directive, where the Chief Information Security Officer (CISO) must be an internal member of staff who reports to the board. That puts the "translate-into-board-speak" work on the CISO. He gives the example of the organization not having sufficient coverage across user identifies with Multi-Factor Authentication (MFA) enabled. This, he argues, has to arrive at the board as a business exposure risk with a cost and a plan attached, or it will not be acted on.

Penalties and management liability

Accountable but without the authority

Jane Frankland MBE has argued for years that CISOs carry accountability for cyber risk without the authority to reduce it. Responsibility for security and resilience falls to the CISO, patching to IT and infrastructure, and the budget to fix either is held elsewhere again. When the risk persists, the CISO still answers for it.

The board has been on the other side of that arrangement, and the same habit shows up there.

That is the change Frankland thinks matters most, and also the one she is most cautious about. The liability exists on paper. Whether it turns into board members asking harder questions depends on enforcement, and she says it is too early to tell.

Frankland describes the broader goal as "cyber survivability." The aim is to reduce the impact of an incident, keep critical operations running, and preserve a route to recovery.

For the board, evidence needs to show more than that it was handed a security report. It needs to understand the material risk, approve the measures intended to manage it, and oversee the next steps.

MFA gets difficult as soon as it meets the organization

Article 21 requires organizations to use MFA where appropriate, but the more difficult part is making it work across the organization.

Pavlosoglou describes how quickly the exceptions pile up once mandatory MFA is switched on. In one example, the IT team enables MFA on Monday Morning. By 10 a.m., on the same day, the Director’s office requests to be excluded. As afternoon approaches, the first request for Non-Personal Technical Accounts (NPTAs) to be excluded arrives. Given user accounts have been used for service identities (e.g. to connect to payment systems) enabling MFA breaks the service.

Dinu sees the same user resistance as part of the implementation problem. MFA changes how people work, so deploying it also means dealing with the pushback that follows when a security control adds another step to a familiar process.

Frankland warns against using the directive’s "where appropriate" language as an escape route. In her words, it shouldn’t be interpreted as "if convenient." Authentication strength should align with the asset’s sensitivity and the risk associated with access. Having MFA in place does not mean every authentication method provides the same level of protection. She argues for phishing-resistant MFA such as FIDO2 for higher-risk access.

Ntokos makes a similar point from an operational perspective. Organizations first need an inventory of their infrastructure and an understanding of where critical data resides. They then need to account for different working environments. A factory-floor worker may not be allowed to carry a mobile phone. An office employee and an administrator have different access requirements.

Legacy technology makes that even more challenging. An old application may have no native support for modern MFA. Pavlosoglou warns that organizations can leave gray areas in their policies to accommodate those systems, get the policy approved, and appear compliant without fixing the underlying weakness.

Frankland reaches the same conclusion from the design side. The question stops being how to bolt MFA onto an old system and becomes how to stop that system being reachable with a single credential at all.

One option is to move the authentication control outward. Muntyan describes placing MFA on the credential-management layer and using it to broker access to legacy applications. The application itself does not suddenly acquire modern authentication, but the route to its credentials can be subject to stronger controls.

One authentication method cannot be forced onto every user and system. It is better to know where stronger authentication is needed and have a defensible way of dealing with systems that cannot provide it themselves.

Non-human identities are becoming part of the access problem

Access inventories have traditionally started with employees, but that is no longer sufficient. API keys, service accounts, scripts, and AI agents can all carry authority into critical systems. Some remain active long after the reason for their creation has disappeared.

Muntyan sees another problem in the way secrets are stored. If the approved system is cumbersome, teams find somewhere else to put API keys, tokens, and other credentials. Those “hiding places” create secrets sprawl and make it harder to know which credentials exist or who can use them.

The asymmetry is what worries Muntyan today. Passwords are wrapped in controls that exist because people are expected to fail, and machine credentials have inherited almost none of them. Looking ahead, he expects AI agents to make this worse, because they can create and use credentials at machine speed while access-review processes were designed around people.

Pavlosoglou thinks the cost of token consumption may end up putting a brake on unchecked AI agent usage. Over the summer, he anecdotally quotes the stories of CISOs having to track employees at organizations with strict regulatory controls who were spinning up agents to get tips on World Cup matches.

As that use becomes more expensive, organizations have another reason to track which agents are running and for what. Cost is a blunt instrument, though. It catches the agents someone is watching the bill for, not the ones nobody remembers creating.

Frankland takes the issue beyond authentication. "Authentication tells us who or what is acting, but it doesn't tell us whether the action is sensible."

An agent could authenticate correctly and operate within the permissions it has legitimately been granted while still taking an action the organization would not want.

Ntokos sees this as an identity-management problem that existing systems will have to adapt to. Organizations need to be able to identify agents, monitor their actions, constrain their scope, and revoke or expire their access.

The accountability does not disappear because the actor is software. Dinu argues that using an agent does not transfer accountability to the software, and that responsibility remains with the person or organization that owns or manages the system.

Access teams should stop treating non-human identities as exceptions. They belong in the inventory alongside employees, administrators, and suppliers.

Supplier access needs its own lifecycle

Third-party access fuels a similar accountability problem. Pavlosoglou has been on the security side of long contract negotiations and makes no apology for the time they can require. “The negotiation took ten months,” he said. “The business wanted to know where the contract was. But unless we agreed on how we would treat the suppliers in terms of indemnification clauses, liabilities and the softer but equally important KPIs there was no point in moving forward with the Return of Security Investment (ROSI) the third party would provide.”

That included whether the supplier had to report a breach and when, whether the customer had the right to audit them, and who would pay for the audit. Some of those details can sit deep in indemnification clauses or cyber insurance terms. As Pavlosoglou put it, “even individual words and commas can make a big difference.”

His advice is to start with suppliers who have access to critical systems and review what is already on paper. NIS2 gives security teams a reason to go back to legal and make sure the contracts cover what access those suppliers have.

Dinu sees the same difficulty from the other side of the table. Supply chain security is the Article 21 measure that DNSC’s stakeholders ask about most, and the questions can look basic: which suppliers, which measures, imposed by whom. He reads that as a sign of how hard the requirement is to assess, and the authority faces its own version when writing rules that must fit more than a dozen sectors and every size of entity.

Frankland argues that supplier access should be attributable, limited, and revocable. She is also skeptical of relying too heavily on questionnaires. A completed questionnaire does not prove that the stated controls are operating. Organizations also need to look beyond their direct suppliers and understand where fourth parties could introduce access or dependencies further down the chain.

Ntokos says supplier access needs to be managed throughout the relationship, from onboarding through to exit. The level of access should depend on the work the supplier is doing, with separate or time-limited access where needed.

Muntyan recommends avoiding permanent passwords for suppliers, logging their activity, and rotating credentials when the engagement ends. Those controls also produce something the organization may later need to show: evidence that supplier access was limited and withdrawn when it was no longer required.

Evidence has to survive the incident

NIS2 does not prescribe a single retention period for access logs. Experts have acknowledged the broad misunderstanding that access logs must be retained for 10 months, but argued that the organizations themselves need to determine an appropriate period based on applicable legal requirements, business needs, and their risk assessment. ENISA’s technical implementation guidance similarly calls for retention periods to be defined on this basis.

Retention is only part of the problem. Organizations also need to decide which access records matter, protect them, and make sure they can be produced when an auditor or incident responder needs them.

Access logs are often discussed within this topic, but professionals suggest the more pertinent question is whether those records can be trusted and used.

Pavlosoglou describes the failure case from the regulator’s side. Under NIS2, National Competent Authorities supervise compliance and, in Greece, are obliged to participate when an entity in scope asks for help during an incident. The state of information systems they find on arrival decides how much they can do.

The answer should start with the critical service, he argues. Organizations need to determine which records are necessary to understand activity around that service rather than treating NIS2 as an instruction to log everything indiscriminately.

There is no recovering from that position after the fact. By the time the Authority is in the building, the organization either has the records or it does not, and the money saved by leaving logging off has already been spent many times over.

For Frankland, there’s another problem. Keeping logs is of little use if they can be altered or if activity cannot be reconstructed across different systems.

Ntokos focuses on how that evidence is managed. Organizations need retention and logging policies, appropriate storage, timestamps, synchronization, and chain of custody. Before worrying about how quickly evidence can be retrieved, they need to make sure it has been retained properly.

Muntyan also stresses retrieval. If a regulator or incident responder asks for evidence, he argues that teams should be able to produce it within minutes or an hour, rather than spending days pulling records together from different systems.

Compliance should expose weaknesses, not hide them

A perfect compliance score can be less reassuring than it looks.

Dinu points to Cyber Fundamentals, or CyFun self-assessment approach developed by the Belgian Cybersecurity Authority, in which organizations assess themselves each year, and essential entities submit a plan to address areas of non-conformity. The expectation is not that every control will receive a perfect score. Regulators, he said, would be “quite worried” if they did.

Dinu’s tolerance for imperfect scores comes from watching what happens when regulators demand immaculate ones.

Dinu says an incident can change that attitude quickly. He has seen organizations move from treating cybersecurity as a compliance exercise to taking the risk seriously once they have experienced an attack themselves.

Muntyan says incidents have historically been the trigger for organizations to improve access management, but that is changing. Enterprise customers are increasingly asking suppliers how they manage credentials before they sign a contract. For a supplier, that question arrives before any regulator does, and the person asking it is the customer.

For Pavlosoglou, exposed credentials can provide a more personal trigger. He references the well-known “name and shame” effect, meaning evidence that someone can claim your digital identity makes the risk much harder to dismiss.

Ntokos argues that improvements should follow the risk, instead of waiting for a compliance deadline or an incident. Frankland would also move earlier. Her trigger is the point at which the number of identity systems and credentials becomes too much for people to manage reliably by hand. Waiting for an incident, audit, or compliance deadline means waiting until the weakness has already become a problem.

Access management checklist

What the five experts would fix first

Passwork, built for the evidence question

Passwork is an EU-made password and secrets manager built for organizations that have to show, not just state, how credentials are controlled. 

Its NIS2 compliance capabilities cover role-based access control, customizable vault types, system-wide MFA enforcement, AD/LDAP/SSO integration, and audit logs that can be exported to a SIEM.

Passwork does not decide which services are critical or who should have access to them. Those decisions remain with the organization. What it can do is help put those decisions into practice and keep the records needed to show what happened.

Frequently asked questions