What NIS2 asks of privileged accounts and how open source PAM answers it
If you are an essential or important entity under NIS2, your supervisor will expect you to show who holds administrative rights, how those rights are used, and when they were last reviewed. Point 11.3 of the Annex to Commission Implementing Regulation (EU) 2024/2690 requires policies for privileged and system administration accounts, and an open source privileged access management layer such as Teleport or JumpServer can enforce much of that policy and record the evidence. Implementing Regulation 2024/2690 is written for listed digital sectors such as DNS, cloud, data center, CDN, managed service providers, online platforms and trust service providers. Many other NIS2 entities use it as a practical reference for their own privileged access controls, and national transposition laws in your Member State will set the obligations that actually apply to you.
The regulation's requirements translate into a few concrete design decisions. Point 11.3.2 calls for strong identification and multi-factor authentication, dedicated accounts used only for administration, individualized privileges, and administrative accounts that connect only to administration systems. Point 11.3.3 calls for periodic access reviews with documented results, and point 3.2.3(e) asks for logs of privileged access and administrative activity where appropriate. A bastion such as Teleport, which issues short-lived certificates tied to an identity provider, or JumpServer, which brokers SSH, RDP, Kubernetes and database sessions with recording, addresses the access and logging points directly. The review cycle and the choice of identity source are decisions your organization still has to make and document.
DeployOpen plans, implements and hardens these controls inside your own infrastructure, and prepares the configurations, access lists and session evidence that your assessors will ask for. DeployOpen does not issue audit reports or certifications, and NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Before scoping the work, confirm with your national authority and legal team which requirements apply to your entity, and check the ENISA technical implementation guidance published on 26 June 2025 for examples of evidence that supervisors have seen.
Mapping points 11.3, 11.4 and 3.2.3(e) to PAM configuration
This table maps each privileged access function in the NIS2 implementing rules to the PAM settings that deliver it on Teleport or JumpServer. Read each row as a requirement, the configuration that meets it, and the evidence an assessor will ask to see. The main takeaway is that the identity provider, the access request workflow and the session recording store must be designed together, because a gap in any one of them leaves the admin account requirement unmet.
| Requirement function | Configuration to set | Evidence to keep | Where it usually fails |
|---|---|---|---|
| Strong identification and MFA for admin accounts (11.3.2) | Enforce SSO with MFA at the gateway through the corporate identity provider. On Teleport Enterprise, connect Okta, Microsoft Entra ID, Google Workspace or SAML/OIDC. On JumpServer Enterprise, use the SSO option. Confirm the edition supports your chosen IdP. | IdP login policy export, MFA enrollment report, gateway login logs showing the MFA method used | Teleport Community Edition limits SSO to GitHub, and local passwords remain possible if the gateway is not locked to SSO |
| Dedicated, individual admin accounts used only for administration (11.3.2) | Create separate admin identities per person, distinct from daily user accounts. Disable shared root and shared SSH keys. Use certificate-based access so each session maps to one named identity. | Account inventory with admin and standard accounts linked to one person, list of retired shared accounts | Shared service accounts left in place for scripts, or one admin identity reused by several engineers |
| Individualized, restricted privileges (11.3.2) | Define Teleport roles or JumpServer custom roles per system group and privilege level. Grant only the logins, Kubernetes groups or database users each role needs. | Role definitions exported from configuration, mapping of roles to job functions | Broad wildcard roles copied from defaults, so every admin can reach every server |
| Admin accounts that reach only administration systems (11.3.2) | Route admin sessions only through the bastion or Teleport proxy. Block direct SSH, RDP and database access from user networks with firewall rules and network policy. Restrict admin identities to the proxy path. | Firewall rule set, network test results showing direct access is refused, proxy-only access list | Legacy direct paths kept open for emergency use, or databases reachable from workstation subnets |
| Short-lived credentials instead of standing secrets (11.3.2) | Use Teleport short-lived certificates in place of long-lived SSH keys and Kubernetes tokens. Set certificate lifetimes to match your policy. On JumpServer, rotate stored asset credentials and limit who can view them. | Certificate TTL configuration, rotation logs, inventory of any remaining static keys | Long-lived keys stored on laptops or in CI variables that bypass the proxy |
| Access requests and approvals for elevated rights (11.3.2, 11.3.3) | Require approval for production or high-risk roles. Teleport Enterprise offers just-in-time access requests and reviews, and JumpServer Enterprise offers ticket and just-in-time approval workflows. Community Edition relies on CLI role requests, so confirm approval design before choosing an edition. | Request tickets with requester, approver, time window and reason, approval audit trail | Approvals granted by the requester's own manager without a second check, or no expiry on granted elevation |
| Periodic review of privileged rights (11.3.3) | Schedule access reviews for admin roles at intervals set in your policy. Use Teleport Identity Governance access lists and access reviews, or export JumpServer user and role lists for manual review. Adjust rights after reorganizations and leavers. | Signed review records with reviewer, date, decisions and removals, offboarding tickets | Reviews done from memory rather than from a documented list, and leavers still holding gateway access |
| Administration systems separated and encrypted (11.4) | Deploy the bastion on a dedicated management network segment. Keep its software used only for administration. Enforce TLS on the web interface and encrypted tunnels to targets. Limit the host to administration software. | Network diagram showing the management zone, host hardening baseline, TLS configuration output | Bastion co-hosted with general application servers, or the same host used for ordinary business software |
| Logging of privileged access and admin activity (3.2.3(e)) | Enable session recording for all SSH, RDP, Kubernetes and database sessions. Both Teleport and JumpServer record sessions in both editions according to the feature matrix and product documentation. Forward session and command events to your SIEM and set retention in line with your policy. | Session recording index with user, target and time, SIEM forwarding configuration, retention settings | Recordings not enabled for database or Kubernetes sessions, or recordings stored only on the bastion with no retention plan |
| Protecting and reviewing recorded sessions | Restrict playback to a named audit group. Check that recordings are stored encrypted and that deletion requires a documented process. Confirm which playback and moderation features your edition includes. | Playback access list, storage encryption settings, sample audit trail of who viewed recordings | Recording storage filling up and being purged without a retention decision, or all engineers able to replay sessions |
Does NIS2 apply to your privileged accounts and which entities it reaches
NIS2 reaches your privileged accounts only if your organization is an in-scope entity, and that starts with sector. Directive (EU) 2022/2555 covers 18 sectors: 11 of high criticality listed in Annex I and 7 other critical sectors in Annex II. Article 3 then classifies each in-scope entity as essential or important. Both classes face the same risk-management obligations under Article 21, including the access control measures that point 11.3 of Implementing Regulation 2024/2690 spells out for privileged and system administration accounts. The difference is supervision: essential entities face ex ante supervision and important entities face ex post supervision under Articles 32 and 33. Your privileged account design therefore needs to be defensible for both classes, even if the regulator's first contact would differ.
Regulation 2024/2690 is a detailed technical regulation, but it applies directly only to specific digital sectors such as DNS, TLD, cloud, data center, CDN, managed service providers, online platforms and trust service providers. Most other in-scope entities, including many manufacturers, energy operators and public administration bodies, are bound through their national transposition law, which may add or keep stricter rules under Article 5. Confirm with your national competent authority or legal counsel which text applies to your entity and whether your member state has added requirements for administration accounts. ENISA's June 2025 technical guidance on the 2024/2690 measures is a useful reference for evidence, even where the regulation itself does not bind you.
Scope is also moving. On 20 January 2026 the Commission proposed targeted amendments to NIS2 under COM(2026) 13, including a new small mid-cap category. That proposal still needs approval by the European Parliament and the Council, so treat it as a pending change. Before you design the bastion, record your sector, classification, national transposition law and the regulation text that governs your systems, and review that record each time the proposal advances. NIS2 also creates no certificate of compliance, so the evidence you keep for privileged sessions will be inspected rather than certified.
Teleport or JumpServer for NIS2 administration access
Teleport fits organizations where administrators already work from SSH, kubectl and database clients and where the platform team wants access to follow identity. It issues short-lived certificates through its own certificate authority, so administrators do not depend on shared SSH keys or long-lived Kubernetes tokens. That supports the NIS2 expectations for dedicated, individualized admin identities and for strong authentication on administration systems.
- Certificate-based access: Sessions to SSH nodes, Kubernetes clusters and PostgreSQL, MySQL or MongoDB databases use certificates with automatic expiration, and Teleport states it is compatible with OpenSSH clients and servers.
- Community Edition threshold: The Community Edition license only covers organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Most NIS2 entities will fall outside it, so confirm the license position before design.
- SSO limits in Community: Community Edition single sign-on is limited to GitHub. Enterprise adds Microsoft Entra ID, Okta, Google Workspace, OIDC and SAML, which most regulated identity estates need.
- Approval and dual control: Moderated sessions and dual authorization are Enterprise features, as are Device Trust and HSM support. Just-in-time access requests and access reviews sit under Identity Governance in Enterprise.
- Session recording: Session recording with playback appears in both editions, but the retention, storage and search design still has to be built and tested.
Confirm current edition features, license terms and FIPS or FedRAMP availability directly with Teleport before selecting a tier.
JumpServer fits organizations that need one browser-based workspace for administrators, vendors and operations staff, including Windows hosts over RDP and database and web assets alongside SSH. It is often easier to explain to auditors and operations teams because access runs through a single web interface with central asset, account and session records. Its Community edition is free for self-hosted use, which makes it a common starting point for NIS2 entities with mixed estates.
- Community asset limit: The free self-hosted Community edition is listed for up to 5,000 assets in a standalone topology. Larger estates or a need for high availability will push the design toward paid tiers.
- Enterprise approvals: Ticket and just-in-time approval workflows, password rotation, custom roles, SSO, RADIUS and LDAP HA are listed as Enterprise features, so the approval step that supports point 11.3 depends on the tier chosen.
- High availability: Enterprise Standard offers active-standby HA, Pro offers active-standby HA at 5,000 assets, and Ultimate offers a full HA cluster. Confirm the cluster design, recording storage and failover behavior for your topology.
- Support model: Community is supported through GitHub and the forum. Enterprise adds email and ticket support with an SLA and an account manager, which matters when a NIS2 incident involves the bastion.
- Protocol connectors: Some Enterprise components, such as the RDP proxy and database proxy, are private, so confirm which protocols each edition covers for your systems.
Confirm current tier limits, component availability and support terms with JumpServer before purchase, since the pricing page lists prices by quote.
The choice rarely turns on features alone. It turns on who administers the systems, which protocols they use and whether approvals must be enforced inside the bastion rather than in a ticket system. A short decision exercise with the security, platform and operations teams usually settles the direction before any proof of concept starts.
- Engineering-led with Kubernetes: Teleport fits when most administration is through kubectl, SSH and database clients, and the platform team will own certificate policy.
- Mixed Windows and vendor access: JumpServer fits when RDP, web consoles and vendor sessions dominate, and operations staff need a browser-only workflow.
- Approval enforced in the bastion: Compare moderated sessions and dual authorization in Teleport Enterprise with approval workflows in JumpServer Enterprise, and test each against your change process.
- Scale and HA: Estimate asset count and failover needs early, since JumpServer's Community limit and Teleport's license threshold both change the cost and edition decision.
- Hybrid or both: Some organizations run both, but this doubles recording, identity integration and evidence work, so require a clear reason before choosing that path.
Ask each vendor to confirm the edition features in writing against your specific protocols, identity provider and recording retention requirements.
Which open source platforms fit NIS2 privileged account controls
NIS2 point 11.3 asks for dedicated admin identities, strong authentication, reviewed privileges and logged activity, and no single product covers all of that. The cards below pair each open-source component with the control it supports and the gap it leaves for process, identity or log design.
Teleport for privileged sessions
Teleport issues short-lived certificates through its built-in certificate authority and brokers access to SSH nodes, Kubernetes clusters and databases, so administrators do not hold standing shared keys. Session recording with playback is included in both editions. Check the Community Edition license threshold before you commit, because it limits distributed builds to organizations under a set employee and revenue size. Moderated sessions and dual authorization are Enterprise features, so confirm whether point 11.3.2 needs them in your design.
JumpServer as a bastion
JumpServer provides a single workspace for SSH, RDP, Kubernetes, databases and web access, with a session audit trail that suits administration systems logically separated from other software. Its Community edition is free for up to 5,000 assets in a standalone topology, but approval workflows, password rotation and SSO sit in Enterprise tiers. Confirm which protocols you need, such as Oracle or SQL Server, because some are Enterprise-only. Plan the host as an administration system with its own hardening and patching.
Keycloak or authentik for MFA
Point 11.3.2 requires strong identification and multi-factor authentication for privileged accounts, and a central identity provider is where that policy is enforced once rather than per server. Keycloak supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, while authentik is MIT licensed outside its enterprise directory. Neither product proves that privileged users were enrolled in strong factors, so you still need a review of enrollment and a rule that admin accounts cannot log in with password alone.
midPoint for reviews and leavers
Point 11.3.3 requires privileged access rights to be reviewed at planned intervals, adjusted after organizational changes and documented. midPoint, an identity governance platform under EUPL 1.2 or later, can drive joiner, mover and leaver changes and periodic certifications from authoritative sources. It does not enforce sessions on servers, so its certifications must feed the bastion's role mappings. Confirm the 4.8 Curie long-term support window if you need a stable baseline, since it is supported until October 17, 2028.
OpenBao for secrets and certificates
Privileged access fails when shared service passwords and static keys sit in scripts, so point 11.3.2 pushes you toward dedicated, individualized credentials. OpenBao, licensed under MPL-2.0, can store secrets and issue certificates for administration paths and keep key material under your own control. It does not record who used a credential, and it does not decide who may request one, so pair it with the bastion's approval and audit logs. Decide early how the Community license terms of other vaults affect your choice.
Wazuh or Security Onion for logs
Point 3.2.3(e) expects logs of privileged access and of administrator activity where appropriate, and those logs must leave the bastion and host in a place the admins cannot edit. Wazuh, under GPL-2.0, collects host and endpoint events, while Security Onion bundles network monitoring and the Elastic stack under the Elastic License 2.0. Neither replaces the recorded session itself, and retention and access to log stores need their own design. Verify the license terms before you distribute either product beyond your own organization.
How to roll out dedicated admin identities and recorded sessions
The sequence moves from knowing which privileged and system accounts exist to a documented first access review, with every admin session routed through a gateway that records it. Each step leaves evidence that an assessor or supervisor can check against the Implementing Regulation 2024/2690 requirements for privileged accounts.
Inventory privileged and system accounts
The client's identity and infrastructure team, with DeployOpen, lists every human and non-human account with administrative rights across servers, databases, Kubernetes clusters, network devices and cloud consoles. The inventory records owner, purpose, system, and whether the account is shared, vendor-held or used by a service. Done means the list is signed off by the system owners and every account has a named owner or a documented reason for having none. Effort depends on how many systems and accounts are in scope, which the written fixed scope should state before work begins.
Separate admin identities from daily accounts
Each administrator receives a dedicated admin identity used only for privileged work, with individualized privileges matched to their role. The daily account stays for email and general office work and cannot reach administration systems. Shared and generic admin accounts are retired or restricted to documented break-glass use. Done means every named admin has a separate identity in the directory, and the mapping from person to admin identity is recorded so that each action can be traced to one individual.
Place admin systems on a separated network
The gateway, whether Teleport or JumpServer, runs on an administration network segment that is logically separated from general application software. Admin accounts are allowed to connect only to that gateway, and the gateway alone reaches target systems through network rules. DeployOpen configures the segmentation with the client's network team and tests that direct logins from workstations to targets fail. Done means a test from a non-admin path is blocked and logged, and the rule set is documented as a configuration baseline.
Enforce MFA through the identity provider
The gateway authenticates admins through the organization's identity provider, such as a workforce SSO like Keycloak or the client's existing directory, with multi-factor authentication required for every privileged session. Teleport issues short-lived certificates after login and JumpServer applies its own authentication policy, so the design should state which mechanism applies to each protocol. Done means test logins without the second factor are refused, and the authentication settings are exported as evidence. Edition limits on SSO options should be confirmed in writing before the design is fixed.
Enable session recording and forward logs to the SIEM
Session recording is switched on for all protocols in scope, and recordings are stored in a location the admins cannot edit or delete. Gateway audit events, including login, command activity and role changes, are forwarded to the client's SIEM so that privileged activity can be correlated with other logs. Done means a test session appears in the recording store and its audit events appear in the SIEM with timestamps and user identity. Retention periods are set by the client's legal and compliance owners, not by the implementation partner.
Run the first documented access review
The system owners review each admin identity, its privileges and its target systems against the inventory from the first step, and record the decision for each one. Accounts that no longer need access are removed, and changes are logged with the reason. DeployOpen prepares the review template and the export of current assignments, and the client's owners complete the review. Done means a dated review record exists with reviewer names, decisions and follow-up actions, and the review interval for future reviews is set and written into the access control policy.
Evidence NIS2 supervisors and assessors ask for on privileged accounts
This table lists the evidence items a supervisor or assessor is likely to ask for under point 11.3 of the Annex to Implementing Regulation 2024/2690, and which component usually produces each one. Read each row as a starting point for your own evidence map, since the record must still be reviewed by the entity and its assessor against its own scope and national transposition rules.
| Evidence item | Producing component | What the assessor checks |
|---|---|---|
| Privileged account register | Identity provider and midPoint (where used), exported from the gateway's user and role inventory | Every privileged and system administration account is listed, with an owner, purpose and a dedicated status |
| Admin account naming and dedicated-use policy | Written policy plus identity provider naming rules and gateway role mapping | Admin identities are separate from daily user accounts and are used only for administration |
| MFA enforcement settings | Identity provider authentication policy, exported as configuration and login logs | Strong authentication applies to every path into administration systems, with no unmanaged bypass |
| Role and privilege matrix | Teleport roles or JumpServer permission sets, mapped to identity provider groups | Admin privileges are individualized and restricted to the systems each person needs |
| Access request and approval records | Gateway access request workflow or ticketing system linked to the gateway | Elevated access was requested, approved by someone other than the requester and time-limited |
| Periodic access review records | midPoint certification campaigns or documented gateway review exports | Reviews happen at planned intervals, reflect organizational changes and record the outcome and follow-up actions |
| Session recordings and audit logs | Gateway session recording storage, forwarded to the SIEM such as Wazuh | Privileged sessions and administrator activity are recorded, retained and can be searched during an investigation |
| Separation of administration systems | Network design records, gateway placement and firewall rules documented by the entity | Administration systems are used only for administration, logically separated and protected by authentication and encryption |
What open source PAM does not satisfy by itself under NIS2
Does a PAM bastion alone meet the NIS2 privileged account rules?
No. A bastion enforces part of point 11.3 of the Annex to Implementing Regulation (EU) 2024/2690, such as dedicated admin identities, strong authentication and recorded sessions, but the regulation also expects a documented access control policy, reviews and decisions that tooling cannot make. The entity still owns the policy, the approval of exceptions, the review outcomes and the sign-off. Treat the platform as the mechanism that produces evidence, and the governance around it as the part that must be written, approved and kept current.
What policy and governance documents does an entity need for admin accounts?
The regulation requires policies for privileged and system administration accounts that sit within the access control policy. In practice, the documents an assessor is likely to ask for include:
- A privileged access policy covering who may hold admin roles, how they are requested and approved, and when they expire.
- A standard for dedicated admin accounts and for which administration systems they may connect to.
- A session recording and log retention standard, including who may review recordings.
- A break-glass procedure with named owners.
Confirm the exact document set with your national competent authority and the ENISA technical guidance of June 2025, which gives non-binding examples of evidence.
How often must privileged access rights be reviewed under NIS2?
Point 11.3.3 requires access rights of privileged and administration accounts to be reviewed at planned intervals, adjusted for organizational changes, with the results documented. The regulation does not fix the interval in the supplied text, so the entity must set it, justify it and follow it. A bastion can export role and account lists to support the review, but the reviewer, the decision to remove or keep a right, and the record of that decision belong to the entity. Confirm the cadence against your own risk assessment and any sector guidance that applies to you.
Who handles incident reporting under Article 23 when admin access is involved?
Article 23 of NIS2 sets reporting obligations for significant incidents, and the entity must run that process itself. A PAM platform can show which privileged sessions were active, which commands ran and which accounts were used, which helps the investigation. It cannot decide whether an event is significant, meet the reporting timelines or contact the national authority. Write the link between the incident response plan and the session logs into the procedure, and test it with the people who will file the report.
What supplier and vendor controls must cover privileged access?
Vendor and contractor access is still privileged access, so the entity needs contracts and procedures that cover it. Key points to settle include:
- Named vendor identities, with no shared accounts.
- Approval before each vendor session and time-limited access.
- Recording of vendor sessions and agreed retention.
- Removal of vendor rights when the contract or task ends.
The platform enforces the technical side, but security terms in supplier contracts and the supplier's own staff controls are the entity's responsibility. Ask your implementation partner which of these the chosen platform can enforce and which need a written process.
Does NIS2 require staff training for administrators?
The supplied NIS2 facts do not set a training curriculum for privileged users in point 11.3, so the entity must define what its admins need to know and prove they were trained. Training usually covers when to use an admin account, how approvals work, how break-glass access is logged and why shared credentials are not allowed. Keep attendance records and update the content when the platform or the policy changes. Confirm the training expectations for your sector with your competent authority.
Which national transposition rules change the PAM design?
NIS2 is a directive, so each Member State applies it through its own law, and Article 5 allows national rules that raise the level of cybersecurity. Two entities in the same sector can face different expectations, and the Commission's February 2026 proposal to amend NIS2 (COM(2026) 13) is still before Parliament and the Council. Check the transposition law in each country where you operate, identify whether you are essential or important under Article 3, and confirm with your authority how it reads point 11.3 and what evidence it expects.
Can we run the governance side ourselves after the platform is live?
Yes, many entities own the policy and review process in-house once the technical rollout is finished, provided they have clear owners and time to run reviews. The work that recurs includes access reviews, policy updates after organizational changes, log checks and training. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Ongoing support and upgrades can be arranged as retainers, and the scope is agreed in writing before work starts.
What to ask an implementation partner before signing
Start the written scope by naming the controls. Ask which points of the Annex to Implementing Regulation 2024/2690 the partner will implement and how each one maps to a configuration or process. For point 11.3, that means dedicated administrative identities, strong authentication with multi-factor authentication, individualized privileges, and admin accounts that can reach only administration systems. For point 11.4, ask how the administration systems are logically separated from other application software and how they are protected by authentication and encryption. A scope that says only "PAM implementation" leaves these gaps open. Also ask who signs off on the mapping, since your own compliance lead will need to defend it to the competent authority. Next, pin down the edition and the reasons for it. Teleport Community Edition limits single sign-on to GitHub and allows just-in-time requests only through the CLI, while JumpServer's Enterprise tiers add features such as approval workflows and SSO. Ask the partner to show, feature by feature, why the chosen edition meets your identity provider, approval and session-control needs, and what happens if the organization outgrows the licensed limits. Ask who is named as the licensee and who pays for each license.
Then ask how session recordings are stored, retained and protected. Confirm where recordings live, whether they stay inside your own infrastructure, who can play them back, how they are encrypted, and how long they are kept. Ask how break-glass access is designed: which account is used, who can activate it, how activation is alerted and reviewed, and how the credential is rotated afterwards. For reviews, ask how access rights for privileged accounts are recertified at planned intervals, how changes after reorganizations are recorded, and where the review results are documented. Finally, clarify evidence ownership. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and NIS2 creates no certificate of compliance. Ask the partner to list every artifact it will hand over, the format and the storage location, and who in your organization owns each one after handover. Ask which supervision evidence your national authority accepts, and confirm that with the authority or your legal advisers before the scope is signed.
Keeping privileged access compliant after go-live
After go-live, the privileged access layer needs a recurring cycle of access reviews, change handling, gateway maintenance, log monitoring and evidence refresh, so the controls still match what Regulation 2024/2690 point 11.3 and the national NIS2 rules expect. The sequence produces a current record that shows who holds admin rights, why, and how they were used.
Run scheduled privileged access reviews
The control owner, usually the security or IT governance lead with system owners as reviewers, checks every privileged and system administration account against the current role list in Teleport or JumpServer. Point 11.3.3 requires reviews at planned intervals and documented results, so the review calendar, the reviewer for each system and the decision for each account (keep, reduce or remove) belong in the access control policy. The step closes when a signed review record lists each account, its roles and the action taken, and any removals are confirmed in the platform.
Adjust access for organizational changes
HR or the business owner notifies the security team of transfers, departures and contractor end dates, and the platform administrator updates roles, dedicated admin identities and vendor access accordingly. Point 11.3.3 expects access rights to be adjusted for organizational changes, so the trigger list should be agreed in writing with HR and vendor managers. The step is complete when each change has a ticket, the platform reflects it, and the disabled or re-scoped accounts no longer appear in active role assignments.
Patch and upgrade the gateway
The platform engineering team applies vendor releases and security patches to the bastion, its database backend and the recording storage in a test environment first, then in production. Teleport and JumpServer publish frequent releases, so the team should confirm the current version on each vendor's changelog and release page, check the edition-specific features before upgrading, and keep a rollback plan. The step closes when the upgrade record shows the version before and after, the test results, and a successful login and session recording check for each protocol in use.
Review session logs and alerts
The security operations team reviews privileged session recordings, command logs and alerts for unusual logins, out-of-hours access and failed authentication, and forwards events to the SIEM. Point 3.2.3(e) expects logs of privileged access and of administrative activity, so the review cadence, the sampling method and the escalation path should be documented. The step closes when each alert has a disposition and each sampled session has a reviewer note, with the log retention period confirmed against your own policy.
Re-check controls against new national rules
The compliance lead tracks transposition of NIS2 into national law in each member state where the entity operates, the ENISA technical guidance on Regulation 2024/2690, and the status of the proposed NIS2 amendments. When a rule or guidance changes, the lead maps the change to the affected controls, such as dedicated accounts, MFA and session recording, and assigns owners. The step closes when a dated change memo lists each affected control, the gap found and the configuration or policy update made.
Refresh evidence for assessment
The compliance lead and system owners collect current evidence: the policy, the latest access review records, change tickets, upgrade records, sampled session logs and configuration exports. NIS2 creates no certificate, so national authorities assess compliance through inspections, audits and information requests, and an independent auditor may test the same evidence under other frameworks. The step closes when an evidence index maps each NIS2 point to its current artifact, the owner and the date it was last checked.
Decide on ongoing support with a retainer
The client leadership and the DeployOpen team agree whether internal staff can carry the recurring work or whether a retainer should cover upgrades, continuous support and periodic testing of the access layer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and scope, responsibilities and service levels are set in writing before work starts. Ask any partner which tasks sit inside the retainer, who approves changes, and how evidence is handed over. The step closes when the responsibility split is recorded in a signed scope document.
