Skip to main content
NIS2Certify
Back to overview

NIS2 Access Control and Asset Management: Article 21(2)(i) Explained

By NIS2Certify
NIS2Access ControlAsset ManagementArticle 21MSP
NIS2 Access Control and Asset Management: Article 21(2)(i) Explained

Most NIS2 audits do not fail on encryption or incident response. They fail on a spreadsheet nobody kept current.

An auditor asks for your asset inventory and gets a two-year-old export. They ask who has admin rights to the client's firewall management console and get three names — but the fourth, a contractor who left in March, still has an active account. That is a finding. Often it is the first one, and it colours everything that follows.

Article 21(2)(i) of NIS2 bundles three controls that most organisations treat as separate housekeeping tasks: human resources security, access control policies, and asset management. Auditors treat them as one connected system. If you help clients with NIS2, this is the measure where your own house has to be in order first — because as a managed service provider you sit inside the scope of Commission Implementing Regulation (EU) 2024/2690, which turns these obligations into binding, testable requirements.

Article 21(2)(i) covers three controls auditors read as one story

The directive text is short: entities must have "human resources security, access control policies and asset management." That brevity is misleading. The Implementing Regulation and the ENISA Technical Implementation Guidance (v1.0, June 2025) expand it into some of the most detailed requirements in the entire framework.

The logic is a chain. You classify your assets so you know what matters. You control access to those assets based on that classification. You manage the people who hold that access across their entire lifecycle with you. Break any link and the other two lose their meaning — least privilege is worthless if you never inventoried the systems, and a perfect inventory is worthless if a former employee still holds the keys.

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

You cannot control access to assets you never inventoried

Asset management comes first because everything downstream depends on it. CIR 2024/2690 does not ask for "a list of servers." It requires an asset management policy with several concrete parts.

You need an inventory of network and information systems and their supporting assets — hardware, software, cloud tenancies, and the data they hold. Each asset needs an owner and a classification level. You need handling rules tied to that classification, so a system holding client credentials is treated differently from a marketing website. And you need policies for removable media and for the secure return or disposal of assets when a device or contract ends.

That last point is where MSPs get caught. A laptop reimaged and passed to the next technician without a documented wipe is a gap. A decommissioned client firewall sold on without certificate revocation is a bigger one. The regulation wants evidence that assets leave your control as cleanly as they entered it.

Practical starting point: if your inventory is not automatically discovered and reconciled at least monthly, assume it is already wrong. Manual spreadsheets drift the moment a technician spins up a VM outside the process.

Access control under CIR 2024/2690 means least privilege, enforced and reviewed

Once assets are classified, access control decides who touches them. The Implementing Regulation requires a documented access control policy built on least privilege and need-to-know — access granted because a role requires it, not because it is convenient.

Concretely, auditors expect to see unique identifiers for every user (no shared "admin" accounts), a separate and tightly controlled process for privileged and administrative accounts, and periodic access reviews that actually result in revocations. The pairing with authentication matters here: strong access control assumes strong identity, which is why phishing-resistant MFA is not an optional add-on but the mechanism that makes least privilege enforceable. See our breakdown of NIS2 MFA requirements for how those two measures connect.

The decision an auditor is really testing is simple to state and hard to evidence: for any given account, can you show why it has the access it has, who approved it, and when it was last reviewed?

Does NIS2 Apply to Your Organisation?
1
Does your organisation operate in an essential or important sector (energy, transport, health, digital infrastructure, etc.)?
Yes ↓No →
2
Does your organisation have 50 or more employees, or an annual turnover exceeding €10 million?
Yes ↓No →
3
Is your organisation a critical infrastructure provider or a qualified trust service provider?
Yes ↓No →
✗
NIS2 does not directly apply to your organisation.
✓
NIS2 applies to your organisation as an Essential or Important Entity.
!
NIS2 may apply to your organisation — seek legal advice to confirm your status.
Applies
Possibly applies
Does not apply

Privileged access is where the scrutiny concentrates. Standing admin rights that nobody uses daily are the single most common finding. If a technician needs domain admin twice a month, standing 24/7 access to it is a risk you are choosing to carry. Just-in-time elevation and session logging move that from a finding to a defensible control.

For an MSP, one stale credential cascades across every downstream client

This is why regulators care so much about a control that sounds like IT hygiene. Access control failures do not stay contained.

A single over-privileged, unreviewed account inside an MSP is not one risk — it is a shared risk across every client that account can reach. Compromise it and the blast radius is the entire book of business. This is exactly the supply-chain concern that Article 21(2)(d) is built around, and it is why an access control weakness at a provider triggers scrutiny far beyond the provider itself. Regulators can escalate: a finding at your organisation becomes a finding for every essential entity that depends on you, and the enforcement pressure — including administrative fines and, for management, personal accountability — cascades down the chain.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

The uncomfortable implication for MSPs: your clients' compliance posture is now partly a function of your access hygiene. A client can do everything right and still inherit a gap from your side. Increasingly, that is what supplier questionnaires are probing — see supplier contracts and NIS2 for how this is landing in contract language.

Human resources security is the control nobody documents

The third leg of 21(2)(i) is the one most often skipped, because it lives partly in HR rather than IT. NIS2 expects security to be part of the employment lifecycle.

That means background verification appropriate to the role before access is granted, confidentiality and security obligations written into contracts, security responsibilities that are understood during employment, and — critically — a defined offboarding process that revokes access and recovers assets on the day someone leaves. Not the week after. The day.

The joiner-mover-leaver process is where asset management, access control, and HR security finally meet as one system. A "mover" — someone changing roles internally — is the quiet failure case: they accumulate access from the old role while gaining the new, and nobody revokes the old rights. Six moves later you have an account with access nobody can explain. That is precisely the account an auditor will find.

What an auditor will actually ask you to produce

Evidence, not intent. For 21(2)(i) specifically, be ready to hand over an asset inventory with owners and classification, an access control policy that states least privilege explicitly, a list of privileged accounts with justification and last-review date, records of a completed access review with revocations, and documented joiner-mover-leaver procedures with proof they were followed for recent leavers.

If assembling that list from memory made you uneasy, that unease is the gap analysis. Article 21(2)(i) is one of ten measures, and the measures interlock — a weakness here undermines your incident response, your supply chain assurance, and your business continuity claims. Our step-by-step gap analysis guide walks the full set, and the ten measures explained shows how 21(2)(i) connects to the rest.

Access control and asset management are unglamorous. They are also where readiness is won or lost, because they are the controls an auditor can verify in an afternoon and the ones an attacker exploits in minutes. Find your stale accounts and your missing assets before someone else does.

Not sure where your gaps are? Run a free NIS2 quick scan to see how your access control and asset management posture measures up against Article 21 in about ten minutes.

    NIS2 Access Control and Asset Management: Article 21(2)(i) Explained — NIS2Certify