# Core Infrastructure Access Review for NIS2 Programmes

## 12 questions for server and privileged-access risk management

Use this checklist as a starting point for reviewing who can access critical servers and core infrastructure within a wider cybersecurity risk-management programme. It focuses on SSH-based server access, the area managed by Flotte.

Article 21(2) of the NIS2 Directive expressly includes access-control policies and asset management and, where appropriate, multi-factor or continuous authentication and secured communications. The controls appropriate to an organisation depend on its scope, sector, jurisdiction, risk profile, and applicable national law.

1. **Can you list everyone with access to critical servers?**
   Include employees, controlled service identities, suppliers, and contractors, together with the systems each may access.

2. **Is every privileged server credential assigned to an approved identity?**
   Identify shared, duplicate, unapproved, and ownerless credentials. Document any necessary exceptions.

3. **How are shared-password server accounts controlled?**
   Record who has received the password, where it is stored, when it is rotated, and how activity is attributed. A shared password alone identifies knowledge of a secret, not a specific person.

4. **How quickly and reliably can access be revoked?**
   Verify the process across all in-scope systems rather than assuming that disabling one account removes every key or copied password.

5. **Are privileged credentials time-limited where appropriate?**
   Document certificate or credential duration, renewal rules, operational exceptions, and the risk basis for the chosen lifetime.

6. **How is strong authentication applied to privileged access?**
   Document the authentication method, where MFA is enforced, and the sensitivity of the systems accessed. NIS2 refers to MFA or continuous authentication where appropriate.

7. **Are access requests and approvals documented where required by policy?**
   Record the requester, approver, scope, reason, date, and intended duration.

8. **Are access grants, changes, and revocations logged?**
   Record who changed what, when it changed, and the affected identity and systems.

9. **Are contractor and supplier permissions scoped and time-bound where appropriate?**
   Document purpose, systems, start and end dates, responsible owner, and review status.

10. **Can you show that a departed or reassigned person no longer has access?**
    Retain revocation records and verify the result on relevant systems after termination or role changes.

11. **Can you reconstruct relevant privileged access during an incident?**
    Maintain searchable records tied to verified users or controlled service identities. Account for connections or authentication events not captured by the central platform.

12. **Are privileged permissions reviewed at planned intervals and after significant changes?**
    Define owners, frequency, findings, exceptions, and remediation actions.

## Evidence your organisation may need to collect

- Documented privileged server access-control policies
- Authoritative identities, roles, assets, and current permissions
- Approved access requests and documented exceptions
- Permission grant, modification, and revocation history
- Credential or SSH certificate issuance and expiry history
- Relevant privileged-access records showing identity, system, and timestamp
- Revoked and deactivated identity records
- Authentication architecture and evidence of where MFA is enforced
- Contractor and supplier access scope, duration, and owner
- Completed access reviews, findings, and remediation actions
- Administrative action logs
- Records from servers, identity providers, SIEM tools, and other systems outside Flotte

## Records Flotte may provide for managed activity

Subject to the product version, configuration, deployment, and activity observed by Flotte, the product may provide:

- Current Flotte users and server permissions
- SSH certificate issuance and expiry history
- Revoked or deactivated Flotte accounts
- Administrative actions recorded by Flotte
- Access events recorded by Flotte, where available

Flotte does not claim to produce approval records, completed access-review evidence, failed-login records, identity-provider MFA evidence, or a complete record of SSH activity occurring outside Flotte.

## Important scope and legal boundary

Flotte is a technical product for SSH-based access to servers and core infrastructure. It supports implementation and documentation of a limited set of technical and organisational access-control measures. It is not a complete NIS2 solution and does not make an organisation compliant.

EU Implementing Regulation 2024/2690 contains detailed requirements for specified digital and ICT-service entities. It is not a universal checklist for every organisation potentially covered by NIS2. Applicable requirements depend on the organisation, sector, jurisdiction, risk profile, national implementation of NIS2, and other applicable law.

Product records are not audit attestations, acceptance by an auditor or authority is not guaranteed, and this checklist does not replace legal, regulatory, audit, or professional security advice.

Official sources:

- NIS2 Directive, Article 21: https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
- Commission Implementing Regulation (EU) 2024/2690: https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng

## Learn more

- Join the Flotte waitlist: https://flotte.sh/waitlist/
- Learn how Flotte supports core infrastructure access controls: https://flotte.sh/usecase/nis2/