DORA and Ping Identity: matching authentication to the risk of the access

Article 20(1) requires policies and procedures ensuring the unique identification and authentication of the persons and systems accessing the financial entity's information. This obligation should not, however, be confused with the whole of Article 20: the following paragraph deals with the lifecycle of identities and accounts, which belongs rather to an IGA platform such as Netwrix Identity Manager.

Ping operates on the authentication and access side. Its authentication policies make it possible to define how the identity must be verified depending on the application or journey concerned. PingOne supports single-factor and multi-factor policies and allows those policies to be combined with the access journeys of applications.

Take the case of Claire, an employee of a finance department who needs to access an application supporting an important function. Her IGA can establish that she legitimately holds access to that application. When she tries to connect, Ping takes over to verify her identity according to the authentication policy associated with that resource. Governing the entitlement and authenticating the person are therefore two distinct controls, even though they take part in the same access journey.

DORA does not only require strong authentication on a few predefined perimeters. Article 21(f)(i) also requires authentication methods to be proportionate to the classification of the assets and to their overall risk profile.

This is where PingOne Protect brings a more dynamic answer. The solution makes it possible to build risk policies from different predictors. Ping's documentation cites in particular IP address reputation, geovelocity anomalies, the use of a new device, unusual user behaviour, location anomalies or certain device-related signals.

PingOne Protect makes it possible to combine those signals into a risk evaluation and then adapt the authentication journey. Depending on the policies defined by the organisation, a higher risk level can lead to requesting step-up authentication or to denying access.

For Claire, the rule can therefore differ depending on the situation. A usual connection from her known device can follow the journey planned for the application, while an attempt from a new device combined with a location anomaly can trigger additional authentication or a denial depending on the defined policy. Claire's business access has not changed: what is re-evaluated is the level of trust granted to the authentication attempt.

Ping does not on its own cover the DORA requirements related to identities and access, because several different decisions occur before and after authentication. IGA governs the identity, its lifecycle and the rights it should hold; Ping Identity secures the access and adapts authentication to the context; Axiomatics can make a much finer authorization decision on a given action and resource; a PAM comes in when the use of a privilege must be specifically controlled.

In Claire's case, the journey becomes consistent: IGA establishes that she should be able to access the Finance application, Ping verifies her identity and determines the level of authentication required given the criticality and the observed risk, then the authorization controls of the application decide what she can actually do there. If Claire then uses a privileged account or capability, PAM mechanisms take over on that perimeter.

Ping Identity is therefore not a “DORA solution”. Its contribution is more precise and easier to demonstrate: implementing the authentication controls required by Articles 20(1) and 21(f), making it possible to adapt the level of assurance to the risk of the access and to enforce strong authentication on the perimeters that require it.