DORA and Netwrix Identity Manager: governing identities and entitlements

Article 21 requires rights to be assigned according to the principles of need-to-know, need-to-use and least privilege, including for remote and emergency access.

Netwrix Identity Manager makes it possible to translate this requirement into an entitlement model. Its role model associates technical rights with roles that non-technical users can understand, then allows them to be assigned manually or automatically according to the context of the identity. The Netwrix documentation gives, for example, rules based on department, location or other organisational dimensions.

The benefit is no longer only knowing that a user belongs to a given Active Directory group or holds a given application permission. The organisation can document the rule that justifies access and distinguish rights automatically tied to a job function from sensitive entitlements that require an explicit decision.

Article 21 is particularly precise about maintaining entitlements. It requires the responsibilities for assignment, review and revocation to be defined, access to be removed without undue delay when employment ends or when it is no longer necessary, and it sets a minimum review frequency. Rights must be reviewed at least once a year for ordinary ICT systems and at least every six months for those supporting critical or important functions.

Netwrix Identity Manager answers this need with its certification campaigns. A campaign defines a precise period and scope of entitlements to review. That scope can be filtered by role category, assignment type, last certification date or risk level. The reviewer can then determine whether each entitlement should be kept or removed.

The DORA classification can therefore be used directly to build the certification policy: systems supporting critical or important functions enter a half-yearly cycle at minimum, while the others fall under the annual cycle. Particularly risky rights or SoD conflicts can be reviewed more frequently, without waiting for the regulatory deadline.

Article 21 also covers privileged, administrator and emergency access, which must be granted on a need-to-use or ad hoc basis, as well as authentication mechanisms adapted to the criticality and risk of ICT assets.

That is the boundary to keep in the architecture. Netwrix Identity Manager governs why an identity is eligible for an access or a privilege, but IGA does not replace Access Management for strong authentication, nor PAM when a temporary elevation, an administration account, a secret or a privileged session has to be managed. IAM logs must also be complemented with those of Access Management, PAM and the applications when the goal is to know not only why an access was granted, but what was actually done with it.

The use case is ultimately not “install Netwrix Identity Manager to be DORA compliant”. It consists in using IGA to turn certain precise obligations of the regulation into permanent controls: managing the identity lifecycle, justifying entitlements, detecting incompatible combinations, reviewing rights according to the criticality of the systems and removing them when they are no longer necessary.

The value of the setup then comes from the continuity between the rule and its execution. For a given entitlement, the organisation can retrieve the identity concerned, the justification for the right, the rule or decision that assigned it, its risk level, its last certification and, where applicable, its revocation. It is this traceability that moves access management from declarative compliance to a demonstrable DORA control.