NIS2 PAM Requirements: What Polish Companies Must Implement Before April 2027
The Polish NIS2 transposition act (UKSC) entered force on 3 April 2026. You have until April 2027 to comply. Failure to do so exposes your organization to fines of up to €7 million and — critically — personal liability for senior management. This is not a cybersecurity team problem. It is a board-level problem.
This guide cuts through the noise: here is exactly what NIS2 Article 21 requires for privileged access, and here is how each requirement maps to a concrete implementation step.
What NIS2 Article 21 Actually Requires
Article 21 of the NIS2 Directive requires "appropriate and proportionate technical, operational and organizational measures to manage the risks posed to the security of network and information systems." For privileged access, this translates into ten specific controls that Polish regulators will examine during inspections:
-
Multi-factor authentication on all privileged accounts — every administrative account must require a second factor. SMS OTP does not satisfy the requirement for high-assurance access; TOTP or hardware tokens (WebAuthn/FIDO2) are expected.
-
Session recording for privileged sessions — every RDP, SSH, and administrative web session must be recorded with tamper-proof integrity. The recording must be retrievable for audit purposes for at least 12 months.
-
Audit trail and event logging — every access event (login, session start, session end, command executed, file transferred) must be logged with a tamper-evident timestamp.
-
Least privilege enforcement — users must only have the access they need, when they need it. Standing administrative rights on production systems are not compliant.
-
Just-in-Time (JIT) access — privileged access should be time-boxed. Access is granted for a specific session or time window and automatically revoked afterward.
-
Approval workflows for sensitive access — access to critical systems should require documented approval from a second authorized person before the session begins.
-
Credential vault with automatic rotation — privileged passwords must not be shared, written down, or stored in spreadsheets. Credentials must be stored in an encrypted vault and rotated automatically.
-
Zero standing access to production credentials — users must connect through a brokered session; they must not see or receive the actual password.
-
Access review process — privileged access rights must be reviewed and recertified at regular intervals (quarterly is typical for high-sensitivity systems).
-
Incident response evidence preservation — session recordings and audit logs must be preserved in a way that they can be produced in response to a security incident or regulatory investigation.
How VaultPAM Maps to Each Article 21 Control
| Control | Requirement Summary | VaultPAM Feature |
|---|---|---|
| MFA on privileged accounts | TOTP or hardware token required | Built-in TOTP (Google Authenticator, Authy), WebAuthn (YubiKey, Touch ID, Windows Hello) |
| Session recording | Tamper-proof recording for all privileged sessions | Full video + activity logging for RDP, SSH, VNC, HTTP; BLAKE3 hash chain integrity; WORM storage |
| Audit trail | Tamper-evident log of every access event | Immutable event log: session start/end, commands, clipboard, file transfers — all with timestamps |
| Least privilege | Role-based access to specific targets only | Policy-based access control (PBAC) — users access only explicitly permitted targets |
| Just-in-Time access | Time-boxed session grants | JIT access with configurable session duration and automatic expiry |
| Approval workflows | Second-person approval for sensitive access | Built-in approval workflow — request, approve, reject — with full audit trail |
| Credential vault | Encrypted vault with automatic rotation | Envelope-encrypted vault (AES-256-GCM, Vault Transit); automatic rotation on schedule |
| Zero standing access | Users do not see or receive passwords | Session brokering — VaultPAM retrieves the credential; user never sees it |
| Access review | Regular recertification of access rights | Access review reports and exportable audit logs for recertification processes |
| Evidence preservation | Session recordings retrievable for 12+ months | Configurable retention; MinIO-backed WORM storage; recordings downloadable for auditor review |
Implementation Timeline
Not everything needs to happen on day one. Here is a realistic timeline for a Polish enterprise starting from scratch:
First 30 days — Stop the bleeding
- Deploy VaultPAM in your environment (one afternoon, no agents to install)
- Migrate your highest-risk admin accounts to VaultPAM session brokering
- Enable TOTP MFA for all accounts that access production systems
- Disable direct RDP from the internet (expose access through VaultPAM only)
Why this first: Direct internet-exposed RDP is the single most common initial access vector in ransomware attacks. Eliminating it reduces your risk exposure immediately, even before the full compliance picture is complete.
Days 31–90 — Build the compliance posture
- Enroll all privileged accounts in the vault (disable knowledge of production passwords by operators)
- Configure automatic credential rotation for all production accounts
- Enable session recording for all RDP, SSH, and administrative web sessions
- Set up approval workflows for your five most sensitive production targets
- Export the first access review report for your CISO
Before April 2027 — Close the compliance gaps
- Complete JIT access policy rollout across all production targets
- Implement access review process with quarterly cadence
- Document your privileged access management policy (VaultPAM produces the evidence; you write the policy that references it)
- Run an internal audit simulation: pull a session recording, produce an audit log, demonstrate MFA configuration to an auditor-level reviewer
- Engage your external auditor or CISO for a pre-assessment walkthrough
The Management Liability Question
One aspect of the Polish UKSC implementation that many IT teams have not yet communicated upward: Article 32 of the NIS2 Directive makes management personally liable for failing to implement required security measures. "The IT team was working on it" is not a defense if regulators find that privileged access controls were not in place.
If your organization is subject to NIS2 (and most Polish enterprises in essential and important sectors are), the board needs to see a credible implementation plan with milestones, not a vague commitment to "improve security."
See how VaultPAM satisfies NIS2 Article 21 out of the box. Every required control — session recording, MFA, JIT access, approval workflows, credential vault — ships in the base product, hosted in GCP europe-central2 (Warsaw, Poland) for data residency compliance.