CyberArk NIS2 Compliance: Mapping PAM, EPM, and the Vault to CIR Annex 11.3 — and the 4 Evidence Gaps It Leaves

Search for CyberArk and NIS2 and you will find a dozen vendor pages explaining that privileged access management "supports Article 21". Almost none of them tell you which requirement, in which instrument, at which number.

Here it is. Privileged access management sits at point 11.3 of the Annex to Commission Implementing Regulation (EU) 2024/2690, headed Privileged accounts and system administration accounts. It is not point 6.3 — that is configuration management, under a different Section entirely. Section 11 as a whole is headed as implementing Article 21(2), points (i) and (j) of Directive (EU) 2022/2555 [1][3].

That precision matters more than it looks, because the distance between what CyberArk configures and what a supervisory authority asks to see is not a gap in the tooling. It is a gap in paperwork the tooling was never designed to produce.

Which Rulebook Binds You — and Which One Is Only a Benchmark

In plain terms: the implementing regulation is legally binding on eleven categories of digital provider. If you are not one of them, its Annex is still the most precise description available of what "appropriate and proportionate" means — but you cite it as a benchmark, not as a rule that binds you.

Article 1 of CIR 2024/2690 names its addressees exactly: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplace providers, online search engines, social networking services platforms, and trust service providers [1]. Everyone else in scope of NIS2 — energy, health, water, transport, manufacturing, public administration — is bound by Article 21(2) of the directive itself, which states the obligation but not the technical detail.

Your entity type	What legally binds you	How to use Annex 11.3
One of the 11 categories in CIR Article 1	Article 21(2) and the CIR Annex, directly	Cite 11.3 as the requirement your controls satisfy
Any other essential or important entity	Article 21(2)(i) and (j), plus your national transposition	Cite 11.3 as the interpretive benchmark you chose to follow, and say so explicitly

Getting this backwards is the most common error in vendor-authored NIS2 content. Writing "CIR Annex 11.3 requires us to…" in a manufacturer’s policy document overstates the legal position; writing "we have aligned to CIR Annex 11.3 as the applicable technical benchmark" is accurate and still earns the credit. Our guide to the implementing regulation covers the scope question in more depth.

CyberArk Components Mapped to CIR Annex Section 11

Section 11 runs from 11.1 to 11.7, and privileged access touches five of those seven sub-points. The mapping below pairs each requirement with the CyberArk component that actually delivers it — not the marketing bundle name.

CIR Annex sub-point	What the text requires	Component that delivers it
11.2.2(e), (f)	Maintain a register of access rights granted; apply logging to the management of access rights	Digital Vault safe permissions plus the vault audit trail
11.3.2(a)	Strong identification, authentication "such as multi-factor authentication", and authorisation procedures for privileged accounts	Privileged Access Manager fronted by CyberArk Identity MFA
11.3.2(b)	Set up specific accounts used for system administration operations exclusively	Vault-managed administrative accounts; Endpoint Privilege Manager on the endpoint side
11.3.2(c)	"Individualise and restrict system administration privileges to the highest extent possible"	EPM standing-privilege removal, plus just-in-time elevation and zero standing privileges
11.3.2(d)	System administration accounts are only used to connect to system administration systems	Privileged Session Manager as the enforced connection broker
11.4.2(b), (c)	Administration systems separated logically from other application software; access protected through authentication and encryption	PSM deployed as an isolated jump layer over encrypted channels
11.6.2(f)	"Require separate credentials to access privileged access or administrative accounts"	Vault-held credentials with Central Policy Manager rotation
11.7.1	MFA or continuous authentication, in accordance with the classification of the asset accessed	CyberArk Identity adaptive MFA

Two mechanisms carry most of the weight. The Central Policy Manager rotates credentials on target systems automatically and stores the new values in the vault [5] — that is what makes 11.6.2(f)’s "separate credentials" requirement survivable at scale, because no administrator has to hold or hand around a second password. The Privileged Session Manager brokers the connection so the administrator’s workstation never holds the target credential and never talks directly to the target host, which is the practical reading of 11.3.2(d) and 11.4.2(b) together.

One thing worth naming, because every vendor page implies otherwise: Section 11 does not require session recording anywhere. No sub-point from 11.1 to 11.7 mentions it. Recording is genuinely valuable, but its compliance function is evidentiary — ENISA’s guidance lists "audit trail and monitoring logs that capture the use of access rights" among the examples of evidence for 11.3 [2], and continuous monitoring obligations live in Annex Section 3.2, which we cover in the NIS2 logging and monitoring guide. Treat recordings as proof, not as the requirement itself.

The 4 Evidence Gaps CyberArk Doesn’t Close

ENISA’s implementation guidance publishes, for each Annex sub-point, the "examples of evidences" a supervisor might expect. Read the list for 11.3 and something becomes obvious: almost every item is a document, not a system output [2]. A fully deployed PAM platform closes the control gap and leaves the documentation gap wide open.

Requirement	What the platform gives you	What is still missing	Effort
11.3.1 — maintain policies for managing privileged accounts, as part of the 11.1 access control policy	Enforced technical rules inside the product	The governing policy document itself, approved and version-controlled	Medium
11.3.3 — review privileged access rights at planned intervals and "document the results of the review, including the necessary changes"	A current-state report of who holds what	The review record: who reviewed, when, what was decided, what changed as a result	Low
11.6.2(a) and 11.7.2 — authentication strength appropriate to the classification of the asset	Configurable MFA policies per target	The asset classification scheme from Annex 12.1 that justifies why each tier got the strength it did	High
Article 2(2) — documented reasoning wherever a "where appropriate" requirement is not applied	Nothing — this is outside any tool’s scope	A written, comprehensible justification for each declined requirement	Low

The fourth is the one most teams miss entirely. Article 2(2) of the implementing regulation says that where the Annex qualifies a requirement with "where appropriate", "where applicable" or "to the extent feasible", and the entity considers it not appropriate, it "shall in a comprehensible manner document its reasoning to that effect" [1]. The hedge is not an exemption. Point 11.7.1 is exactly such a provision — if you have decided MFA is not appropriate for a given class of privileged access, that decision is itself a documented deliverable. Our NIS2 MFA requirements guide works through where the line usually falls.

The third gap is the expensive one. Both 11.6.2(a) and 11.7.2 tie authentication strength to asset classification, and asset classification is a separate obligation under Annex 12.1 [1]. You cannot defend "we require hardware tokens here and push notifications there" without the classification scheme underneath it — ENISA asks specifically for "documentation detailing the classification of assets and the associated requirement for MFA protection" [2]. If your asset management work is unfinished, your MFA policy has no defensible foundation, however well the tooling is configured.

The Shared-Account Problem the Vault Doesn’t Solve

Point 11.3.2(c) requires entities to "individualise and restrict system administration privileges to the highest extent possible", and 11.5.2(b) requires linking the identity to a single person [1]. ENISA is blunter still, advising entities to establish rules avoiding generic administration user IDs "such as root" [2].

CyberArk’s core value proposition sits in tension with this. Brokering access to a shared root or Administrator account without revealing its password is precisely what the vault and PSM are for. The result is genuine individual attribution at the front door — every session is tied to a named human — while the account at the far end remains a shared identity.

In our reading, that satisfies the attribution purpose of 11.3.2(c) but does not make 11.5.3 disappear. That provision permits identities assigned to multiple persons only where they are necessary for business or operational reasons, and only where they are "subject to an explicit approval process and documentation", and are accounted for in the risk management framework [1]. A vaulted shared account is still a shared account. The compliant position is to keep it, document the operational necessity, record the approval, and note it in the risk register — not to assume the vault removed the obligation. This is a textual reading rather than settled supervisory practice, so document your own reasoning rather than relying on ours.

When a Privileged Account Compromise Starts the Reporting Clock

For the eleven categories the CIR binds directly, there is a link between privileged access failure and incident reporting that no PAM vendor mentions. Article 3(1)(e) of the regulation makes an incident significant where "a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption" [1].

A compromised domain administrator account is close to the textbook case. Significance is what triggers the Article 23 notification sequence, so for a relevant entity the practical consequence is that a confirmed privileged-account compromise capable of severe disruption should be treated as reportable on its own facts — without waiting to measure downtime or financial loss against the other criteria in Article 3(1). Entities outside the CIR’s eleven categories apply their national transposition of the Article 23(3) significance test instead, which is why the local threshold is worth confirming before an incident, not during one.

What the Palo Alto Acquisition Changes for Your Supplier File

Palo Alto Networks completed its acquisition of CyberArk on 11 February 2026. The company states that CyberArk’s Identity Security solutions "will continue to be available as a standalone platform", with integration into the wider Palo Alto ecosystem under way and no disruption expected for existing customers [4]. Product pages have already migrated to Palo Alto Networks domains under the Idira brand.

Nothing about your Section 11 controls changes. Your Article 21(2)(d) supplier documentation does. The legal counterparty and the corporate group behind a critical security supplier have both changed, which is a reportable fact for the directory of suppliers required under Annex Section 5 — and a prompt to re-check whether your existing contractual security clauses survived the transfer intact. If you also run Palo Alto network or detection products, this is now a genuine supplier-concentration question rather than a theoretical one, and it belongs in the risk assessment rather than in a footnote. Our supply chain security guide sets out how that assessment is expected to be structured.

Role by Role: What to Do in the Next 30 Days

Role	Priority action
CISO / IT security manager	Confirm PSM enforcement is mandatory rather than advisory — 11.3.2(d) is not satisfied if administrators can still reach targets directly. Verify the administration tier is logically separated per 11.4.2(b).
Compliance officer	Produce the three missing documents: the privileged access policy under 11.3.1, the periodic review record under 11.3.3, and the Article 2(2) justification for every declined "where appropriate" requirement.
IT / platform lead	Reconcile the vault inventory against the shared accounts still in use, and prepare the 11.5.3 necessity-and-approval record for the ones that must stay.
Board / management body	Note the supplier change from the Palo Alto acquisition in the risk register, and confirm the access control policy is on a defined review cycle — 11.1.3 requires review at planned intervals and whenever significant incidents or significant changes to operations or risks occur.

Related identity platform mappings are covered in our guides to Microsoft Entra ID and Okta, both of which face the same evidence gap from a different starting point.

Frequently Asked Questions

Does deploying CyberArk make an organisation NIS2 compliant?

No, and no tool can. CyberArk addresses a substantial share of Annex Section 11’s technical requirements, but Section 11 is one of thirteen Annex sections, and even within it the policy, review-record and justification obligations are documentary. Compliance is assessed against the whole of Article 21(2), not a single control domain.

Is CIR 2024/2690 mandatory for our organisation?

Only if you fall within one of the eleven provider categories listed in its Article 1. For all other essential and important entities, Article 21(2) binds and the CIR Annex functions as the most detailed available benchmark for what appropriate measures look like.

Does NIS2 require privileged session recording?

Not explicitly. No sub-point in Annex Section 11 mandates session recording. It is a strong source of the audit-trail evidence ENISA lists for point 11.3, and it supports the monitoring and logging obligations in Annex Section 3.2, but it is evidence rather than a standalone requirement.

Can we keep using shared administrator accounts if they are vaulted?

Vaulting gives you individual attribution, which addresses the purpose of 11.3.2(c). It does not remove point 11.5.3, which permits shared identities only where operationally necessary and requires an explicit approval process, documentation, and treatment within the risk management framework. Keep the account if you need it, and keep the paperwork with it.

What changed when Palo Alto Networks acquired CyberArk?

Technically, nothing in your control set — the platform continues to be sold standalone. Contractually and for supply chain purposes, your supplier records, contract clause review and concentration analysis all need updating to reflect the new corporate owner as of 11 February 2026.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal of the European Union
2. Implementing Guidance on Commission Implementing Regulation (EU) 2024/2690 (draft for public consultation, October 2024) — ENISA. Note: this guidance is advisory and not legally binding.
3. Article 21 — Cybersecurity risk-management measures, Directive (EU) 2022/2555
4. Palo Alto Networks Completes Acquisition of CyberArk — Palo Alto Networks, 11 February 2026
5. Privileged Access Management — Palo Alto Networks / CyberArk product documentation
6. Endpoint Privilege Manager — Palo Alto Networks / CyberArk product documentation

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.