NIS2 Doesn’t Require On-Premises Hosting: What the Directive Leaves European Buyers to Decide

Does NIS2 require on-premise credential management?

A 2026 NIS2 access management report from European password and secrets manager Passwork brings together national cybersecurity authorities and independent experts on how that responsibility works in practice.
National implementations and sector-specific rules may add requirements around hosting or data location, so those still need to be checked. NIS2 itself leaves the deployment choice with the organization.
The last is how the buyer leaves. A credential manager is hard to replace in a hurry, so an exit plan means a tested way to export vaults and logs if the provider fails, changes its terms, or stops meeting requirements.

Key insights

  • NIS2 does not require on-premise credential management and does not prescribe cloud; Article 21 asks for appropriate and proportionate measures based on risk.
  • A hosted password or secrets manager is a supplier under Article 21(2)(d), and an unusual one, because it holds the access to most of the organization’s environment.
  • Buyers need answers on who can read the vault, where the data is held, how fast the provider reports a breach, and how they would exit.
  • Self-hosting moves key custody, data location and exit in-house, and adds patching, availability and backup responsibilities the security team must carry.
  • Recital 90 names third-country influence and provider lock-in as supply chain risks, and GDPR Chapter V governs any transfer of personal data outside the EEA.
  • Contributors to a 2026 NIS2 access management report by Passwork say the organization keeps the main liability for delegated work, so the deployment decision needs a documented, reviewable record.

Hosting belongs in the risk assessment

In preparation, they should keep the reasoning with the decision. Record which critical services and credentials are involved and where the data will reside. If a provider will hold or process it, document what you established about that provider and any jurisdiction or dependency concerns that affected the choice.
That choice should not disappear into an old procurement file. When the service comes up for renewal, go back to the risks that justified it and check whether they are still the same.
The record should also explain whether your own team can operate the chosen deployment securely and what happens if the provider relationship ends. Revisit that record when the service comes up for renewal, the provider changes where or how data is handled, or your requirements change.
In his view, a third party is liable only for what the contract states, and the main responsibility stays with the organization.

Just because somebody’s filled that in doesn’t mean that it’s true.

Keeping credentials on infrastructure you control can reduce reliance on a hosted provider. However, a credential store in your own data center still needs to be patched and maintained, its access controls have to work, and the people responsible for it need to know how to keep it secure.
No. The directive does not require organizations to self-host their password or secrets manager, nor does it prescribe a cloud deployment.
If personal data is transferred outside the European Economic Area, GDPR Chapter V governs transfers to third countries. For example, personal data can currently flow from the EU to US companies certified under the EU-US Data Privacy Framework, which the European Commission recognized as providing adequate protection in July 2023.

For credential management, buyers need to know where their data will be stored or accessed and which legal entity controls it. Those details become more important when data crosses borders.

NIS2 Article 21 lists supply chain security among the risk-management measures entities must take, including the security of their relationships with direct suppliers and service providers. When deciding which measures are appropriate, organizations must consider “the vulnerabilities specific to each direct supplier and service provider” and the overall quality of their products and cybersecurity practices.
The same due diligence must be exercised for other jurisdictions. While that doesn’t create an NIS2 requirement to keep credentials on-premise, it does give the organization more to consider when choosing a provider and deciding where its credential data can reside.
[Organizations are] more dependent on suppliers and third parties and cloud services that they don’t always own or control.

Self-hosting moves some of those answers in-house, such as key custody, data location and exit, to address sovereignty compliance concerns, and replaces them with others the security team must cover, including patching, availability, backups, and the security of the people running it.

Often there’s a focus on third parties as opposed to fourth parties.

That decision is under pressure. An appeal against it is pending at the Court of Justice of the EU, and after the US Supreme Court ruled in June 2026 that the President can remove Federal Trade Commission commissioners at will, the European Data Protection Board asked the Commission to assess whether the framework still functions as intended.

Organizations might need to explain a hosting decision made during procurement years later, possibly by people who were not involved at the time.

Self-hosting brings its own work

The third is what happens during an incident. Article 23 requires an early warning to the Computer Security Incident Response Team (CSIRT) or competent authority within 24 hours of becoming aware of a significant incident. If the provider is breached, the buyer depends on the provider’s notification to start that process with accurate information, so the contract needs to state how fast the provider reports and what it shares. The buyer also needs access to the logs showing who used its credentials, in a usable form, when an investigation starts.
His point was that running controls yourself can bring technical constraints that do not exist in the same form with a major cloud provider.
Jane Frankland MBE of KnewStart, a cyber survivability strategist and former Managing Director at Accenture, describes the dependency NIS2 responds to:
A hosted password or secrets manager is one of those service providers, and an unusual one. Granted, suppliers touch part of an organization’s environment, but a credential manager holds the access to most of it: administrator passwords, service account credentials, API keys, and the accounts third parties use to get in. If the provider is compromised, the incident does not stay with them alone.
For a hosted credential service, that loss of control shows up in specific questions the buyer has to answer before signing.
The first is who can read the vault. Hosted services differ in how they encrypt stored credentials and who holds the decryption keys. A buyer needs to know whether the provider’s staff, or an attacker who breaches the provider, could reach credentials in readable form or only encrypted data.

Jurisdiction can affect the decision

Article 21 mandates appropriate and proportionate cybersecurity measures based on the organization’s risk exposure, the state of the art, and implementation costs. However, the Directive does not express any guidance on location, on-premises, or in the cloud.
Gabriel Dinu, Deputy Director at Romania’s National Cyber Security Directorate (DNSC), where he oversees regulatory affairs, control and certification, approaches third-party risk from the regulator’s side:
Dinu was speaking about delegated work in general. Applied to a hosted credential service, it means the buyer owns the answers to the questions above, whatever the provider’s paperwork says.
NIS2 recognizes supply chain risks that have little to do with a software vulnerability. Recital 90 includes potential undue influence by a third country over suppliers and service providers, and also raises concerns about technological lock-in and dependence on a provider.
Dr. Yiannis Pavlosoglou, Vice Governor at Greece’s National Cybersecurity Authority and a former UK CISO at UBS, raised a related issue when discussing these types of access controls more broadly. MFA, for example, can be “simple to implement” when organizations use cloud-based technologies from major providers, he said, while on-prem systems can make the same job much harder.

Write down why you chose the deployment

A provider’s certification tells the buyer something about its controls, but the answer to these questions lie with the buyer’s own deployment. Frankland, speaking about supplier security questionnaires, warned:
NIS2 only focuses on whether you can enforce least-privilege access, use phishing-resistant MFA, and produce reliable audit logs during an incident or audit. So organizations have to choose a deployment model and be able to explain the risks they considered when making that decision.
It’s a balancing that needs to be factored into deployment decisions. Keeping control of your credential data on your own infrastructure only helps if your team can maintain the controls needed to protect it.
If I’m delegating something to someone, I have to take into account all the liabilities, and I am the first one that is responsible for them.
The second is where the data sits and who else is involved. A hosted service may run on another company’s cloud infrastructure, which adds a fourth party to the chain and may add another jurisdiction. Frankland pointed out that supply chain reviews tend to stop one link short:

Similar Posts