Central permissions
Designed to show and manage which verified users have permission to access each Flotte-managed server.
Core infrastructure access controls
Know who can access your critical servers
Control eligibility for SSH access to core infrastructure from one place, update it during offboarding, and maintain useful operational records.
Flotte's scope is limited to SSH-based access to servers managed through the product.
Short-lived access
Configurable certificate lifetime
Identity connected
OIDC integration with provider MFA
Access overview
Permissions and issuance records
What the legislation says
NIS2 includes access-control policies and, where appropriate, stronger authentication
Article 21(2) of the NIS2 Directive includes access-control policies and asset management. It also includes, where appropriate, multi-factor or continuous authentication and secured communications among its cybersecurity risk-management measures.
The appropriate and proportionate measures depend on the entity, sector, jurisdiction, risk profile, and national implementation. Flotte focuses on the server-access controls relevant to its product scope.
Scope matters
EU Implementing Regulation 2024/2690 contains more detailed access-rights requirements for specified digital and ICT-service entities. Applicability depends on the type and scope of the organisation.
The access gap
“Can you show us who can access production right now?”
For many organisations, answering means asking the infrastructure team to inspect every server, identify old credentials, find their owners, and reconcile them against employee and supplier records.
A written offboarding policy alone may not demonstrate effective implementation if a former employee's key remains on in-scope machines.
production — manual access review
$ ssh prod-01
$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3... alice@company
ssh-ed25519 AAABC3... laptop
# Who owns “laptop”?
# Jeff left three months ago. Is this his key?
# 29 more production servers to check
An active key still grants access—even when its owner has left.
Why passwords do not solve it
A shared password proves that someone knew the secret, not who accessed the server
Passwords can authenticate knowledge of a secret, but a shared password does not establish an individual identity. Once copied into a password manager, script, ticket, or chat, there is no reliable way to know who still has it.
When someone leaves, disabling their company account does not erase a password they already know. The organisation must rotate it everywhere it was used, update every dependent automation, and prove that no unmanaged copy remains.
Questions a password-based process must answer
- Who has ever received or seen this password?
- Where has it been copied, stored, or embedded in automation?
- When was it last rotated—and what triggers the next rotation?
- Was it rotated everywhere after each employee or contractor left?
- Can an access event be attributed to one verified individual?
- Can one person's access be revoked without disrupting everyone else?
Identity-based access changes the model
Flotte is designed so each person authenticates through the company identity provider and receives a short-lived certificate. Removing eligibility disables future issuance without coordinating a shared secret rotation across the fleet Flotte.
From policy to control
Support implementation and review of an infrastructure access control
Flotte is designed to give teams a current view of who is eligible to access each managed server, instead of requiring them to reconstruct who received public keys and shared passwords.
Company identity and MFA
Designed to connect server access to your company identity provider and its authentication policies.
Access that expires
Designed to replace open-ended credentials with short-lived access that expires automatically.
Central revocation
Designed to stop future certificate issuance centrally; certificates already issued would remain valid until their configured expiry.
Central access overview
Designed to show current permissions for managed servers and certificate issuance recorded by Flotte.
Self-hosted deployment
Designed for deployment within infrastructure operated by your team.
NIS2 to Flotte
A practical access-control mapping
This mapping connects common infrastructure-access risks to Flotte capabilities. Certificate lifetimes are configurable, while MFA is governed by the configured identity provider and the organisation's authentication policy.
NIS2 concernCommon problemFlotte capability
NIS2 concernAccess rights
Common problemKeys remain on servers indefinitely
Central user-to-server permissions
NIS2 concernLeast privilege
Common problemEngineers accumulate access over time
Explicit, scoped permissions
NIS2 concernOffboarding
Common problemFormer employees' SSH keys can remain active on servers after they leave
Central revocation of future access
NIS2 concernPrivileged accounts
Common problemShared credentials obscure who authenticated
Certificates tied to verified identities
NIS2 concernAuthentication and MFA
Common problemServer access is disconnected from company identity
OIDC, with MFA enforced by the identity provider
NIS2 concernThird-party access
Common problemSuppliers receive open-ended credentials
Access grants can be scoped and certificates expire automatically
Free practical checklist
12 questions to prepare for an infrastructure access review
Review identity, expiry, MFA, offboarding, supplier access, and supporting records before the next management review, audit, or customer questionnaire.
Download the free checklist- 01Can you list everyone with access to critical servers?
- 02Is every privileged credential associated with a known individual?
- 03How quickly can access be revoked?
- 04Do credentials expire automatically?
- 05Is MFA applied before privileged access is granted?
- 06Can you prove an offboarded user no longer has access?
Coming Soon
Make core-infrastructure access easier to review
Give infrastructure teams a self-hosted way to manage SSH-based server access, reduce reliance on open-ended credentials, and maintain useful operational records.
Replace unmanaged
authorized_keys, one control at a time.