Use case — Complying with DORA
DORA and Keeper: protecting credentials, secrets and privileged connections
DORA requires privileged, emergency and administrator access to be granted on a need-to-use or ad hoc basis. The regulation also requires generic or shared accounts to be limited as far as possible and users to be identifiable for the actions performed in ICT systems. Finally, Article 12 requires the logging of events related to access control.
Keeper operates on that perimeter with several capabilities grouped around KeeperPAM and Keeper Secrets Manager: credential management and rotation, privileged connections, session control and recording, tunnels, application secrets and reporting of PAM activities.
The angle differs from that of Netwrix Privilege Secure. Here the starting point is the privileged secret or credential itself: how to allow its use without multiplying its exposure, how to renew it and how to keep a trace of the connection that used it.
Avoiding exposure of the privileged credential: DORA Article 21
DORA requirement
Article 21(e)(ii) — Privileged, emergency and administrator access
- Need-to-use / ad hoc
Article 21(c) — Limit generic or shared accounts as far as possible
- Keep users identifiable
KeeperPAM
- Credential vault
- Privileged connections
- Connection without exposing the credential
- Tunnels
- Credential rotation
An administrator account or a technical account may remain necessary even when permanent privileges are being reduced. The difficulty is then to control the use of its credential without distributing it to the various users who occasionally need it.
KeeperPAM makes it possible to launch privileged connections from the vault and documents in particular the ability to share a connection without exposing the underlying credentials. The platform also offers time-limited tunnels and Zero Trust connections to protected resources.
This separation between the user and the secret used to establish the connection is particularly useful with administration accounts or legacy technical accounts. It does not remove the need to comply with Article 21(c), which requires generic and shared accounts to be limited as far as possible: PAM must not become a pretext for multiplying them. Where such an account remains necessary, the objective is on the contrary to control precisely who is authorised to use it and to retain traceability of its use.
Reducing the lifetime of credentials
DORA does not set a universal password rotation frequency and does not prescribe Keeper. Rotation must therefore not be presented as a literal obligation of the regulation.
It is nevertheless a particularly relevant protection mechanism for privileged credentials. KeeperPAM provides an automated credential rotation capability and also makes it possible to trigger certain rotations on demand. The Keeper documentation describes PAM environments configured for connections, tunnels and rotation of the accounts associated with resources.
The point is to reduce the time during which a given secret remains exploitable and to avoid an administrative password becoming information durably known to several operators. The level and frequency of rotation nevertheless remain a security policy decision specific to the organisation.
Extending governance to application secrets and machine identities
DORA requirement
Complementary case — Machine identities and application secrets
Keeper Secrets Manager
- Secrets outside the code
- SDK
- CLI
- Applications and devices
- Controlled retrieval of secrets
A complementary capability useful for controlling technical access, not the literal transcription of a DORA article.
Privileges do not only concern human administrators. Applications, scripts, CI/CD pipelines and services also use secrets to access databases, APIs or infrastructure.
Keeper Secrets Manager is designed to provide these secrets to applications and technical environments without embedding them hard-coded in the code. Keeper provides SDKs for several languages as well as a CLI allowing a process to retrieve or inject secrets from the vault.
The Keeper Secrets Manager model uses dedicated applications and client devices. Their initialisation relies in particular on a one-time access token used to establish the keys and identifiers needed for subsequent access; after initialisation, requests are signed with the device keys.
This capability is not a direct answer to all of Article 21(e)(ii), which mainly targets privileged, emergency and administrator access. It nevertheless makes it possible to extend control over secrets to non-human identities, which are also a source of sensitive access to the information system.
Human access
Application access
Intended effect
- The secret is not scattered.
- It is stored, distributed and used within a controlled path.
- Its lifetime can be reduced.
Controlling and recording privileged sessions
DORA requirement
Article 12 — Logging of events related to access control
Keeper
- Privileged sessions
- Session recording
- PAM reporting
- Events usable by the logging framework / SIEM
Contribution to evidence, not a complete DORA logging framework.
KeeperPAM also provides privileged session management functions with recording and playback, and the product documentation provides for reporting of PAM events as well as SIEM integration.
This capability contributes to DORA's Article 12, which requires the logging of events related in particular to logical access control. It makes it possible to link the use of a privileged credential to an observable connection and activity, rather than limiting the evidence to the existence of the account.
Here too, Keeper does not replace the complete DORA logging chain. The regulation also covers ICT system activities, change management, operations and network traffic. PAM events must therefore join the organisation's overall logging and investigation framework.
Keeper and Privilege Secure are not two mandatory building blocks
KeeperPAM and Netwrix Privilege Secure both cover part of the PAM ground, in particular privileged access and sessions. It would therefore be incorrect to draw a DORA architecture in which the two products would necessarily be deployed one behind the other.
The choice depends on the problem to be solved and on the existing landscape. Netwrix Privilege Secure lends itself particularly well to a scenario in which an administrative activity triggers the temporary granting of a privilege, possibly after approval, and then its removal at the end of the session. Keeper for its part brings strong coverage around the credential, its rotation, the application secret, the connection without exposing the credential and the management of privileged sessions.
The perimeters may therefore overlap. An architecture must start from the use cases, the resources, the types of accounts and the operating model before deciding whether to favour one of these approaches or possibly combine them on distinct perimeters.
Where Keeper fits into the DORA architecture
An IGA can determine who is eligible for privileged access and control its legitimacy over time. Access Management verifies the identity of the person presenting themselves. Keeper then comes in when the credential or secret used to reach the resource must be secured, when the connection must be controlled and, depending on the use case, when the secret concerned must be renewed automatically.
For human access, this can mean that an administrator opens a connection without knowing the password of the account used and that the session is recorded. For an application, it can mean that a secret is retrieved dynamically from Keeper Secrets Manager rather than stored in the code or in a configuration file.
Keeper's contribution to DORA must therefore remain precisely formulated: reducing the exposure of privileged credentials and secrets, better framing their use and producing traces of PAM activities. It is part of the framework for controlling privileged access, not standalone DORA compliance.
Sources
Regulatory texts — EUR-Lex
Going further
Complying with DORA: which controls?
The master page: mapping of DORA controls on identities, access, privileges and data.
Netwrix Privilege Secure
The DORA subpage dedicated to temporary privilege and control of administrative activities.
PAM service
The Ariovis service: control of privileged accounts and operations.
Secret rotation
The definition of secret rotation in the IAM glossary.
Machine identity
The definition of machine identities in the IAM glossary.
Discuss your secrets and privileged access
Ariovis supports the control of credentials, secrets and privileged connections, from administrator accounts to technical and application identities.