What NIS2 Article 21(2)(i) asks for, and why the NIS2 access control work is hard
If your entity is essential or important under NIS2, a national authority can ask you to show that the people who touch your systems, the accounts they use and the assets those accounts reach are all under control. Article 21(2)(i) covers that combined duty. The implementing regulation, Commission Implementing Regulation (EU) 2024/2690, splits it into three strands: human resources security (Annex section 10), access control (section 11) and asset management (section 12), with physical access control added under point 13.3. Read the Article 21 text on EUR-Lex for the statutory wording, then the Annex sections for the detail an assessor will test.
The risks differ by strand. Human resources security addresses the insider and the careless joiner: background verification for designated roles before the person starts, clear termination steps, and a disciplinary process. Access control addresses who can reach what, and it is where most gaps appear in practice. Access rights must follow need-to-know, least privilege and separation of duties, be changed when someone leaves or moves role, be recorded in a register and be reviewed at planned intervals. Asset management addresses what you run and where it sits, including rules for deleting data irretrievably and a technical block on removable media unless there is an organizational reason to allow it.
The work is hard because identities and assets accumulate faster than anyone reviews them. A single person may hold a directory account, several application accounts, a service account and a shared login that nobody has retired. Each one must link to a single person, shared identities need explicit approval, and unneeded identities must be deactivated without delay. Without an authoritative directory and automated deprovisioning, the register an assessor asks for is out of date by the time it is produced. Start by confirming which system is the source of truth for identities, how many applications still keep local accounts, and who signs off on access reviews. Those three answers set the scope of any implementation work.
Which people, identities, assets and third parties fall under NIS2 access control
Article 21(2)(i) is only as wide as the population it covers. Each scoping choice below decides which people, identities and assets must appear in access registers, reviews and asset records, so the evidence set should be defined before tooling is configured.
Staff with designated security roles
Personnel assigned to security functions, such as administrators of firewalls, identity systems and logging platforms, sit inside the Implementing Regulation's personnel review requirement. Their assignments must be reviewed at planned intervals and at least annually, so the evidence set needs dated role assignments and records of each review. Confirm which roles your entity has designated and who approved them.
Contractors and managed service staff
External engineers, consultants and managed service provider staff who hold accounts are part of the access population even though they are not employees. Their identities need the same life cycle controls: approval before access, removal when the engagement ends, and entries in the access register. Ask each supplier how it notifies you of personnel changes and whether its staff use your identities or their own.
Service accounts and shared identities
Service accounts used by pipelines, backups and integrations often sit outside normal joiner and leaver processes. Shared identities are permitted only with explicit approval, and each needs a named owner, a recorded purpose and a credential rotation route. Inventory these accounts first, because they are the most common gap between the access register and the systems actually in use.
Cloud and on-premises assets
Asset management covers the full life cycle of hardware, virtual machines, containers, SaaS tenants and data stores, wherever they run. A cloud account and a data center rack both need owners, classifications and documented deletion. Scope them together in one asset register, because a register that lists only on-premises hardware will miss cloud resources that carry the same access risk.
Removable media and endpoints
Connecting removable media must be technically prohibited unless an organizational reason exists, so the scope includes USB ports and other removable interfaces on endpoints and servers. The evidence is the technical control configuration, the exception register with approvals, and records of blocked connections. Confirm whether exceptions are time-limited and who reviews them.
Physical access to facilities
Point 13.3 of the Implementing Regulation covers physical access control, so badge systems, server room doors and visitor logs fall within the same review as logical access. Entities that run their own data centers or server rooms need the physical access list reconciled with the logical access register. Ask whether your facilities team keeps records that your security team can produce on request.
How an assessor tests the people, access and asset requirements
This table sets out how an assessor typically tests each people, access and asset requirement under Article 21(2)(i), the evidence they ask to see, and the findings that most often come up. Read each row as a checklist of what to have ready before a supervisory inspection or security audit.
| Requirement area | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| Background verification | Whether designated security roles were screened before the person started those duties, where this is feasible for the entity | Role register marking designated roles, screening policy, dated screening records, exceptions with documented reasons | Screening policy exists but no record links it to specific roles, or screening happens after start date |
| Termination and role change | Whether access is removed or adjusted when someone leaves or moves role, and how quickly | Leaver and mover tickets, deprovisioning logs from directory and applications, HR-to-IT notification records | Leavers keep access to secondary applications, SaaS tools or shared accounts after the HR exit date |
| Access rights register and reviews | Whether access follows need-to-know, least privilege and separation of duties, and whether it is recorded and reviewed at planned intervals | Access register by system and role, approval records, review campaign results with reviewer sign-off and revocations | Register is incomplete, reviews are rubber-stamped, or conflicting roles are held by one person without a documented exception |
| Identity life cycle | Whether each user identity maps to one person, shared identities have explicit approval, and unneeded identities are deactivated without delay | Identity inventory, shared account approvals, dormant account reports, provisioning and deprovisioning audit trails | Shared service accounts with no owner, duplicate identities for one person, or dormant accounts still enabled |
| Asset life cycle and deletion | Whether asset handling rules cover acquisition through irretrievable deletion and whether disposals follow them | Asset inventory with owners, disposal certificates or wipe logs, media sanitization records, handover checklists | Assets missing from the inventory, retired devices without wipe evidence, or backups of decommissioned systems left in place |
| Removable media | Whether connecting removable media is technically blocked unless an organizational reason is documented and approved | Endpoint policy settings, exception register with approvals, device control logs | Policy states removable media is banned but endpoints allow USB storage with no technical control or exception record |
| Physical access control | Whether physical access to facilities and equipment rooms is restricted, logged and reviewed, including visitors | Access badge lists, visitor logs, periodic review of physical access rights, camera or entry log retention settings | Badge holders who have left remain active, or visitor logs are incomplete or not reviewed |
How to build the joiner, mover and leaver chain for NIS2
This sequence ties every person and asset to a recorded owner from hire to disposal, so an assessor can trace each access right and each device back to a documented decision.
Inventory identities and assets
Build one inventory of user identities, service accounts, groups and the assets they touch, including laptops, servers, cloud resources and removable media. Assign each identity to a single named person and each asset to an accountable owner. The output is a dated inventory with owners, reviewed by the security lead. Ask the team to confirm that no shared or orphaned accounts remain unexplained before the inventory is treated as complete.
Designate personnel to security roles
Management or the security lead identifies which roles carry security responsibilities, such as administrators, security operations staff and asset custodians, and records who holds each role. The Implementing Regulation expects this assignment to be reviewed at planned intervals and at least annually. The output is a role register signed off by management, which becomes the reference for background verification and access requests.
Run background verification before start
For roles designated in the previous step, run background verification before the person begins those duties, to the extent feasible under national law and employment rules. HR owns the check, and legal confirms what may lawfully be collected. The output is a completed verification record per designated role, stored with restricted access. Ask counsel to confirm local limits before the process is written down.
Provision access through documented rules
Grant access only after approval tied to the role, following need-to-know, least privilege and separation of duties. Use a central identity source with single sign-on, so each application receives accounts from one place. Where an application supports SCIM, automate creation and removal. The output is an approval record for each access right, linked to the role and the identity owner.
Change or revoke access on move and leave
When a person changes role or leaves, the identity system must remove access that no longer fits and deactivate unneeded identities without delay. Shared identities exist only with explicit approval and a recorded owner. Offboarding covers accounts, tokens, devices and physical access. The output is a dated change or termination record that matches the identity system and the access register.
Maintain the access register and review it
Keep a register that lists each access right, its approver, its grant date and its change history. Schedule periodic reviews where designated reviewers decide to keep, change or revoke each item within a set timeframe, which counters access accumulation. The output is a signed review record per campaign, with revocations traced to tickets. Confirm review frequency with your own policy and the assessor's expectations.
Dispose of assets irretrievably
At end of life, sanitize or destroy storage so data cannot be recovered, and remove asset records from the inventory. Enforce the rule that removable media cannot connect to systems unless an organizational reason is documented and approved. The output is a disposal certificate or log per asset, including the method used and the person who verified it, linked back to the original inventory entry.
Which evidence passes an assessment of NIS2 access and asset controls
Supervisors test Article 21(2)(i) by asking for records that show a control operated, not only a policy that describes it. The cards below cover the artifacts that usually satisfy Implementing Regulation (EU) 2024/2690, and the routine that keeps each one current between audits. The organization owns these records; an implementation partner can set up the systems that generate them.
Background verification records
Keep a signed record for each role the entity has designated as security-relevant, showing that the check was completed before the person started those duties. Under point 10.2, verification applies to the extent feasible, so the file should also record any role where a check was not possible and the compensating step taken. Review the designated role list whenever a job description changes, and confirm with the HR function that the list still matches the roles that hold privileged access.
Termination checklists with timestamps
Each leaver should have a dated checklist showing when accounts were disabled, group memberships removed, tokens revoked and hardware returned. Assessors compare these timestamps with the HR exit date to test whether identities were deactivated without delay. Ask the identity team to export the deactivation log monthly and attach it to the checklist so that the evidence does not depend on a single ticket.
Access rights register
The register lists who holds which rights, on which systems, under what business need, and who approved them. It must show need-to-know, least privilege and separation of duties, and it should be generated from the directory or identity provider rather than typed by hand. Confirm that every entry links to a named person, that shared identities appear with their approvals, and that the register is snapshotted at each review cycle.
Periodic review records with reviewer decisions
A review record names the reviewer, the access items reviewed, and a keep, change or revoke decision for each item, with the date it was completed. Access certification campaigns in midPoint can produce this trail, including decisions taken within a set timeframe. Keep the campaign definition, the reviewer list and the revocation tickets together so an assessor can follow one access item from review to removal.
Shared identity approvals
Point 11.5.3 allows shared identities only with explicit approval, so each shared account needs a written approval naming the owner, the systems covered and the people allowed to use it. Keep the approval linked to the account record in the directory, and review it on the same cycle as other access. Accounts that exist without an approval are a finding in their own right, so the directory query for unapproved shared accounts should run on a schedule.
Asset inventory and disposal records
The asset inventory must cover the full life cycle, including hardware and software, owners, classification and location. Disposal evidence should show irretrievable deletion, for example a sanitization log or a destruction certificate from the party that performed the work, tied to the asset record. Reconcile the inventory against directory and cloud account data each quarter, and confirm that retired assets are removed from the register as well as from the premises.
What meeting Article 21(2)(i) costs in money and effort
This table lists the cost components of meeting Article 21(2)(i), who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none are supplied for this topic, so use the list to structure a quote request and to compare bids on the same scope.
| Cost component | One-time or recurring | Who is paid or who carries the effort | What drives it up or down |
|---|---|---|---|
| Identity and access tooling or licenses | Recurring for commercial products, none for self-hosted open source | Software vendor for licenses; the entity for hosting and staff time | Number of identities, target applications and whether a commercial license is chosen. Confirm license terms with each vendor. |
| Engineering time to integrate target applications | One-time, with ongoing effort when applications change | Internal platform team or an implementation partner under a written scope | Count and age of applications, support for SCIM or OIDC, and whether custom connectors are needed |
| HR process change for joiners, movers and leavers | One-time design, recurring operation | HR, line managers and IT together; the entity owns the process | Number of HR systems feeding identities and how many roles need background verification |
| Review effort by named reviewers | Recurring at each planned review cycle | Named reviewers in business and IT; the entity owns the decision | Number of access items, number of reviewers and how often reviews run. Access certification tooling can reduce manual collation. |
| Asset inventory and disposal work | One-time inventory, recurring for new assets and disposals | Asset owners, IT operations and, for media destruction, a certified disposal provider if used | Size and variety of the estate, data sensitivity on devices and whether removable media controls are technically enforced |
| Evidence upkeep | Recurring | Compliance lead and system owners; a partner may prepare evidence exports | Automation of logs and exports, number of systems in scope and how often the assessor asks for samples |
| External testing or independent review | Recurring, usually tied to audit or supervisory cycles | Independent assessor or security testing firm, chosen and paid by the entity | Scope of the review, whether internal audit covers the area and how many systems are sampled. Ask for the scope in writing. |
Which self-hosted open-source tools can produce NIS2 access evidence
Access evidence under Article 21(2)(i) comes from a small set of identity components working together: a directory, a provisioning path, a review workflow and a single sign-on layer. The four tools below each cover one of these roles, and none of them makes an entity compliant on its own. The entity must confirm fit for its own environment, including which systems it must connect and who owns each access decision.
authentik SCIM provisioning
authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, and runs a full sync every hour. Its main evidence value is deprovisioning: when a user loses access to an application, the account is removed from the target, which produces a traceable record for the leaver requirements in point 11.5 of the Annex. Check which target applications support SCIM in your estate, because any application without it needs a manual or scripted removal step with its own log. The license is MIT.
FreeIPA and 389 Directory Server
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It gives one authoritative source for identities, supports centralized access control and delegated administration through its web UI and command line tools, and so produces the account register that supports the requirement to link each identity to a single person. Confirm which systems can authenticate against it and who holds delegated administrator rights. FreeIPA is licensed under GPL-3.0-or-later, which affects how modifications are distributed.
midPoint access certification
midPoint's access certification campaigns assign designated reviewers who decide within a set timeframe whether to keep, change or revoke access items such as role assignments. The campaign record shows who reviewed what and when, which is the evidence for periodic review of access rights and for segregation of duties. Confirm that reviewers are independent of the access they approve, and set the review interval according to your own risk assessment. midPoint is licensed under EUPL-1.2+, so check the obligations that apply if you modify and distribute it.
Keycloak single sign-on and brokering
Keycloak provides single sign-on so users authenticate with Keycloak rather than each application, and supports OpenID Connect, OAuth 2.0 and SAML 2.0. It can also broker logins to existing OpenID Connect or SAML 2.0 identity providers. Central sign-on gives one place to log authentication events and to disable a user, which supports the deactivation of unneeded identities without delay. Confirm that every application is actually routed through Keycloak, since any local accounts left outside it weaken the evidence. Keycloak is licensed under Apache-2.0.
Who owns the controls, who prepares the evidence and who issues the verdict
The entity owns Article 21(2)(i). Its management body must approve the measures and oversee them under Article 20, and that accountability cannot be handed to a supplier. Human resources decides which roles are security-relevant and must record background checks, onboarding and termination steps. IT and identity teams decide who gets access and approve exceptions such as shared identities. Asset owners decide how equipment is classified, retired and wiped. The security function sets the policy, reviews access reports and tracks findings to closure.
- Management body: approves the policy, the risk treatment decisions and any accepted exceptions to access or asset rules.
- HR function: maintains the list of designated security roles, background verification records and the termination checklist.
- IT and identity owners: run the access register, approve joiners, movers and leavers, and review access at planned intervals.
- Asset owners: keep the inventory current, define retention and irretrievable deletion, and approve any removable media exception.
- Security lead: sets the annual review of security role assignments and signs off evidence before it goes to an auditor.
Confirm with your counsel which named individual carries each of these duties, because supervisors will ask for a named owner and a dated record.
An implementation partner can configure the systems that produce evidence and prepare the records a supervisor will request. DeployOpen works this way: it plans, integrates and hardens self-hosted open-source platforms inside the client's own infrastructure, then documents the result. The partner does not make the access decisions, approve exceptions or attest to compliance. Those remain with the entity. Work is usually scoped in writing before it starts, so the entity knows which identity, directory and asset tasks are included.
- Integration and configuration: connects identity sources, provisioning, single sign-on and directory services so joiners and leavers flow through one process.
- Evidence preparation: exports access registers, certification campaign results, provisioning logs and asset records in a form the entity can hand over.
- Testing: checks that deprovisioning works in a test environment and that access reviews produce the decisions they should.
- Documentation: writes runbooks and procedures that describe how the controls operate, for the entity to adopt.
- Knowledge transfer: trains the entity's administrators so they can operate the platform after handover.
Ask the partner to list in writing what it will not do, such as approving access requests or signing evidence on the entity's behalf.
National competent authorities oversee NIS2 compliance through inspections, security audits, security scans, information requests and administrative fines. Essential entities face ex ante supervision and important entities face ex post supervision. NIS2 creates no certificate of compliance, so there is no single NIS2 verdict that an organization can display. Where a supervisor or the entity commissions an independent security audit, that assessor issues its own findings report. Assessors test what the entity can show, so the entity must keep evidence that stands on its own.
- Inspections and information requests: the authority asks for policies, registers and logs, and tests whether they match practice.
- Security audits and scans: an independent auditor or scanning provider tests access and asset controls and reports findings.
- Findings and remediation: the entity responds with corrective actions, which the authority may verify later.
- Enforcement: non-compliance can lead to administrative measures and fines under the Article 34 regime.
- Other certifications: if the entity also holds ISO/IEC 27001 or another scheme, the certification body issues that certificate, not NIS2.
Confirm with your national competent authority which audit or evidence format it expects and whether an independent assessor's report is acceptable to it.
Where organizations fall short on access and asset controls, and how to close each gap
The most common shortfall under Article 21(2)(i) is not a missing policy but identities and assets that nobody can trace to a person or an owner. Shared accounts are often used for administrative or service work without anyone approving them, and user identities are frequently reused across people. The closing step is to require written approval for every shared identity, record who holds it and why, and link each remaining user identity to exactly one person. Then check the directory for orphaned or duplicate accounts. Under Implementing Regulation (EU) 2024/2690, shared identities are allowed only with explicit approval, so the approval record is itself evidence an assessor will ask for.
Access that accumulates is the gap assessors find most often. People move between roles, keep the rights of their previous job, and nobody removes them. Leavers stay active because the offboarding ticket never reaches the systems that matter. The fix has three parts: tie access to roles so a role change triggers removal of the old rights, deactivate unneeded identities without delay when someone leaves, and run periodic certification campaigns in which named reviewers keep, change or revoke each role assignment within a set timeframe. Open-source tools can automate parts of this. For example, the authentik SCIM provider deprovisions users from a target application when they lose access, and midPoint's access certification campaigns record reviewer decisions. Confirm with each vendor whether a given connector covers your target applications before you rely on it.
Assets without an owner and removable media left open are the last two gaps. An asset inventory that does not name an accountable owner cannot show who approves disposal, and handling rules that stop at purchase miss irretrievable deletion at end of life. Removable media is typically allowed by default. The closing step is to assign an owner to every asset, define handling rules for its full life cycle including verified deletion, and technically block removable media unless the organization records a specific reason for an exception. Ask your auditor or consultant which evidence they expect for the exception register, because the implementing regulation requires the technical prohibition itself, not only a policy statement.
Questions buyers ask about NIS2 access control and asset management
How much effort does NIS2 access control and asset management take?
The effort depends mainly on how many systems, identity sources and asset classes you have, and on how much of your access model is already documented. Most of the work is not technical installation. It is building a complete inventory of users, accounts, groups, hosts and assets, assigning an owner to each, writing rules for joiners, movers and leavers, and then proving those rules run every time. Ask any consultant or partner to split their quote into discovery, design, configuration and evidence production, because the evidence work recurs and is often underestimated. Confirm with your competent authority or assessor which evidence format they expect before you size the effort.
How long does it take to put NIS2 access control in place?
Duration is set by the state of your current identity and asset records, not by the tools alone. An organization with a central directory, a single identity provider and a maintained asset register is far closer to ready than one where accounts live in individual applications and spreadsheets. Plan separate phases for policy approval, identity consolidation, deprovisioning automation, the first access review and the asset lifecycle, including irretrievable deletion. No duration figure is supplied for this work, so request a phased timeline with dependencies in any written scope before you commit.
What does the internal team need to provide for this work?
The internal team must own the decisions that a regulator will hold management to, even when an outside party builds the systems. That means named owners for each system and asset class, a designated person for security roles reviewed at least annually under point 10.1.3 of the implementing regulation, HR input on background verification and termination procedures, and managers who certify their staff's access. Engineers must have time to validate deprovisioning and remove shared accounts. Partners can prepare configuration and evidence, but they cannot approve access or accept risk on your behalf.
Can we implement NIS2 access control in-house with open-source tools?
Yes, a capable internal team can use open-source components for much of this, provided it has the skills to operate them. authentik's SCIM provider can push user and group changes to target applications and deprovision users who lose access, with a full sync every hour. FreeIPA, which uses 389 Directory Server, provides a centralized LDAPv3 directory with delegated administration. midPoint access certification campaigns let designated reviewers keep, change or revoke access items within a set timeframe. Keycloak provides single sign-on over OpenID Connect, OAuth 2.0 and SAML 2.0. Confirm each product's current capabilities and supported integrations against its documentation before you design around them.
What will the auditor or supervisor sample when testing access control?
Assessors typically sample real accounts and trace them back to evidence. Expect them to pick a set of users, including privileged and shared identities, and ask who the person is, whether the identity maps to one individual, who approved access, when it was last reviewed, and when it was removed after a leaver or role change. They will also check the access register, sample a privileged account for explicit approval, and test whether an unneeded identity is deactivated without delay. For assets, they may ask for the inventory, owners, a disposal record showing irretrievable deletion, and the policy that blocks removable media unless there is a recorded organizational reason. Confirm the exact sampling approach with your competent authority or chosen assessor.
What are the main cost drivers for this measure?
Costs fall into one-time work and recurring work. One-time costs include identity consolidation, integration of applications, asset discovery, policy drafting and the first access review. Recurring costs include access certification cycles, joiner, mover and leaver handling, asset disposal, tool licensing or support, and annual role reviews. Costs rise with the number of applications without central identity, the number of privileged and shared accounts, and the size of the asset estate. For any quote, ask what is included in each phase, who operates the tooling afterwards, how evidence is retained, and what happens when a scope change occurs. No cost figure is supplied here, so ask for a written, itemized scope.
When is it worth bringing in an implementation partner?
A partner is worth considering when your identity estate is fragmented, when you need deprovisioning to run across many applications, or when your internal team cannot staff the build and the evidence work at the same time. A partner can plan the design, implement and integrate self-hosted platforms inside your own infrastructure, document configurations, and prepare evidence for assessment. DeployOpen works on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it does not issue audit reports or certifications. Only an independent auditor, assessor or certification body issues assessment outcomes, so budget for that separately.
How DeployOpen works on this
DeployOpen plans, implements and hardens self-hosted open-source identity, access and asset tooling inside your own infrastructure, so the records that show Article 21(2)(i) is operating are produced by your systems. We prepare the controls and evidence for your assessment; your management body owns the policies, role decisions and sign-off, and independent assessors decide compliance.
How we scope
- We confirm which roles, identity stores, applications and asset classes fall under the measure before any work starts.
- The written scope names the designated security roles, background verification triggers and the systems that will hold access registers.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Your quote follows from that written scope, so ask us to list each system and process it covers.
How we build
- We deploy identity and directory services such as FreeIPA, Keycloak and authentik within your cloud accounts or data centers.
- We configure provisioning and deprovisioning so access ends automatically when a person leaves or changes role.
- We set up access certification campaigns in midPoint so designated reviewers keep, change or revoke role assignments on a schedule.
- We test removable media controls and asset disposal steps, then document the results for your assessor.
How we hand over
- You receive configuration records, the access register design, and runbooks for joiner, mover and leaver processes.
- We document how each identity links to one person and how shared identities are approved and reviewed.
- We provide the evidence set your assessor will ask for, including sample exports and review records.
- Final policies and role appointments remain with your organization, and we confirm each handover item in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover recurring access reviews, annual personnel role reviews and changes to connected applications.
- We can re-test identity flows after platform upgrades so the evidence stays accurate between assessments.
- Ask us to confirm which support tasks stay with your staff and which move to a retainer in the quote.

