NIS2, the CRA and privileged access
We give concrete, verifiable answers to the access control and logging requirements of NIS2 and to the product requirements of the Cyber Resilience Act. We also say what is not the product's job.
Per-user identification
Every connection is attributable to a named person, even where the target has a shared support account.
Least privilege
By default the system signs you in with the lowest sufficient privilege level. A higher level is available only to those for whom it is in scope.
Separation of duties
Domain-admin access can be denied at group level in a way that cannot be overridden for any customer.
Logging and accountability
Audit log retention is configurable: 24 months by default, configurable up to five years or more, with a floor of 4 months because of the append-only protection. Who, when, which server, which role, which domain, how much active and idle time, which request. Exports to CSV.
Access review
The permission matrix is visible and exportable in one place, so review is not assembled from interviews.
Protecting secrets
The user never sees the password, and it never leaves the organisation's network. Stored with AES-256-GCM encryption or in your existing vault.
The Cyber Resilience Act
Of the 22 requirements in Annex I, 21 are met, and for each one we can show you the evidence. The single gap is regular, independent security testing, which has not happened yet. That is a procurement item rather than a development one. NIS2 is about the organisation and the CRA is about the product, and we deliberately keep the two apart.
Component transparency
Every release ships with a machine-readable component inventory (SBOM). When a bundled library turns out to be vulnerable, it tells you which versions are affected.
Release hygiene
The dependency check on the release path fails the release on a known Critical or High severity vulnerability. It parses the detailed output, not the exit code.
Secure defaults
Documented setting by setting: the value, where the code sets it, and what breaks if it is changed. Most security-critical defaults are deliberately not configurable.
Protection against unauthorised access
The zone matrix invariants run in an exhaustive test and against the live matrix, and the zone separation report can be exported.
Confidentiality
At rest, envelope encryption with key rotation that needs no downtime. In transit, measured TLS 1.3 with certificate pinning, and both ends refuse an unencrypted connection.
Integrity
A signed package with a signature check that hard-fails before installation. The audit log is protected by an append-only trigger and an HMAC-signed seal chain whose key is not in the database.
Availability
Rate limiting across the whole API, per user, in four bands. Not by IP address, because a dozen technicians work behind one terminal server from the same address.
Exploit mitigation
ASLR, DEP and CFG enabled on each of the three shipped executables. We measured it: the raw output and the script are in the documentation.
Data minimisation
Retention periods justified table by table, derived from the live database schema.
Vulnerability handling
Acknowledgement within two business days, a substantive answer within ten, a ninety-day embargo, a public advisory process and remediation targets tied to severity.
Incident reporting
A ready runbook for the regulation's 24-hour, 72-hour and 14-day reporting deadlines, with the mandatory content and a template.
Update distribution
A versioned share: the installer never overwrites the executable, it only swaps the pointer file. Minimum versions are enforced selectively.
- There is no CE marking, and the product is not CRA-compliant: meeting Annex I is not the same as conformity, which also needs a conformity assessment and an EU declaration of conformity. The regulation applies in full from 2027-12-11.
- Independent security testing has not happened yet: our automated tests are functional, not security tests. This is the one remaining gap, and it will not close by itself with the next release.
- Compliance, as with NIS2, is a property of the organisation: VisionDesk adds evidence to your case, not conformity.
What VisionDesk does not do
- There is no session recording: if your audit requires recorded sessions, you will need a separate tool.
- There is no automatic password rotation.
- There is no vulnerability scanning, SIEM function or incident response: VisionDesk is an access management tool, not a security platform.