Use case — Complying with DORA
DORA and Netwrix Privilege Secure: granting privilege at the moment it is needed
The Delegated Regulation (EU) 2024/1774 deals explicitly with privileged access. Its Article 21(e)(ii) requires privileged, emergency and administrator access to be granted only on a need-to-use or ad hoc basis for all ICT systems. The same article states that, where possible, dedicated accounts shall be used for administration tasks and that, where feasible and appropriate, financial entities shall deploy automated Privileged Access Management solutions.
Netwrix Privilege Secure answers precisely that problem: replacing, as far as possible, a permanent privilege with a privileged activity bounded in time. The platform uses access policies to define which users may perform which activities on which resources. An activity session can then temporarily grant the privileges required for the intervention.
Turning a permanent administration right into temporary access: DORA Article 21(e)(ii)
DORA requirement
Article 21(e)(ii) — Privileged, emergency and administrator access granted on a need-to-use or ad hoc basis
- Privileged, emergency and administrator access
- Need-to-use or ad hoc assignment
- Where possible: dedicated administration accounts
- Where feasible and appropriate: automated PAM solutions
Netwrix Privilege Secure
- Access policies
- Activities
- Pre-Session Grant
- Post-Session Remove
- Approval
- Maximum duration
- RDP / SSH sessions
- Session recording
The risk of an administrator account is not only linked to the person who holds it. It also comes from the time during which that privilege remains exploitable. A permanent right can be used long after the end of the need that initially justified it, including after the account concerned has been compromised.
Privilege Secure makes it possible to define Activities composed of actions executed before, during and after a session. The Netwrix documentation explicitly provides for Pre-Session (Grant) actions granting a right before the intervention and Post-Session (Remove) actions removing the right when the session ends. Netwrix gives as an example the temporary addition of a user to a local administrators group.
Take an administrator who has to work on a server supporting an important function. The organisation may consider that they are legitimate to carry out this type of intervention without leaving them a permanent administrative privilege. Privilege Secure can prepare the session, assign the permissions defined by the policy, allow the intervention, and then execute the removal actions defined at the end of the activity.
This mechanism directly reflects DORA's need-to-use or ad hoc logic: the privilege is associated with a determined operation rather than with the mere existence of the user account.
Submitting sensitive interventions to approval
A privileged intervention may also require an additional decision before it is executed. Privilege Secure makes it possible to associate an approval workflow with a connection policy. When a session requires that approval, it cannot start until the required approvers have accepted the request. The product allows several successive approval levels to be defined where the context requires it.
The request retains in particular the requester, the target resource, the account used, the activity concerned, the planned dates, any notes and a ticket number. The duration of the session is also derived from the maximum duration defined in the connection profile.
In a DORA approach, the value lies in being able to tie the use of a privilege to an identifiable intervention and, where the policy requires it, to an approval decision. Not all administrative operations must necessarily go through the same workflow: it is up to the organisation to make the control proportionate to the risk of the resource and of the activity.
Controlling the privileged session
DORA requirement
Article 12 — Logging of logical access control
Netwrix Privilege Secure
- Active and historical sessions
- Session recording
- Information related to the privileged activity
Contribution to evidence, not a complete DORA logging framework.
DORA's Article 12 requires events related to logical access control to be logged and the level of detail of the logs to allow their use for monitoring and detection purposes.
Privilege Secure can record sessions going through its RDP and SSH proxies when that option is enabled in the connection profile. The Netwrix documentation provides for viewing a live session, replaying it later and recording data such as keystrokes and certain metadata. For SSH, commands and keystrokes are indexed and searchable; administrators can also terminate an active session.
The dashboards also retain active and historical sessions with their user, their resource, the connection account, the activity, the dates and the duration. Execution logs are available for each session.
These elements contribute to the evidence of privileged use but do not on their own constitute the logging framework required by DORA. PAM logs must fit into the wider log policy covering systems, applications, identities, networks and the other events covered by Article 12.
Where Privilege Secure fits into the DORA architecture
Privilege Secure comes after identity governance. An IGA can determine that an administrator is eligible for certain responsibilities; Access Management verifies their identity at the required assurance level; Privilege Secure then frames the actual exercise of the privilege by controlling the resource, the activity, the duration, any approval and the session.
This separation avoids using PAM as a substitute for IAM governance. The objective is not to place every access indiscriminately in a bastion, but to reserve reinforced control for the operations that genuinely justify a privilege and to avoid, where the architecture allows, keeping that privilege permanently.
Netwrix Privilege Secure is therefore not a “DORA solution”. Its contribution is more precise: it makes it possible to translate the requirement of Article 21(e)(ii) into temporary, controlled privileged access, while providing part of the traces needed to audit it.
Administrator
IGA
The administrator is eligible for this activity.
Authentication
The identity is verified.
Netwrix Privilege Secure
Privileged activity request
Approval
only where the policy requires it
Pre-Session — Grant
Granting of the required privilege
RDP / SSH session
- Target resource
- Bounded duration
- Recording where configured
Post-Session — Remove
Removal of the privilege
Sources
Regulatory texts — EUR-Lex
Official Netwrix Privilege Secure documentation
Going further
Complying with DORA: which controls?
The master page: mapping of DORA controls on identities, access, privileges and data.
Keeper
The DORA subpage dedicated to credentials, secrets and privileged connections.
Netwrix Identity Manager
The DORA subpage dedicated to identity governance and access certification.
PAM service
The Ariovis service: control of privileged accounts and operations.
Least privilege
The definition of least privilege in the IAM glossary.
Discuss your DORA privileged access
Ariovis supports the definition of PAM use cases, the reduction of permanent privileges and the implementation of controls adapted to sensitive administrative operations.