DORA and Axiomatics: applying least privilege at the moment of the action

Article 21(a) requires that access to ICT assets rest on the need-to-know, need-to-use and least privilege principles, including for remote and emergency access. An RBAC model can answer part of this requirement by giving a person the rights associated with their role, but it reaches its limits when the decision depends simultaneously on several characteristics of the user, the resource and the requested action.

Take the case of Claire, a Senior Analyst in the Finance France department. Her IGA may legitimately grant her the “Finance Analyst” role, but that role alone cannot decide whether Claire should be able to view every financial file, modify certain information or perform an operation involving another entity of the group.

Axiomatics makes it possible to build a decision from attributes belonging to four categories: the subject, the action, the resource and the environment. The vendor's documentation mentions, for example, for the subject, the role, the department or the clearance level; for the action, viewing or modifying; for the resource, the file or object concerned; and for the environment, elements such as location, time or device type. These attributes are evaluated dynamically at the time of the request.

In our example, the policy could therefore take into account the fact that Claire belongs to Finance France, requests to view file FIN-2026-00452, that this file belongs to the France entity and carries a given classification. The role remains useful information, but it becomes one of the elements of the decision rather than the whole policy.

This approach also avoids creating a new role for every possible combination of function, entity, data type or action. Axiomatics presents PBAC precisely as an alternative to overly static authorization models: policies are centralised and use attributes to adapt authorizations without having to change the entire role model or code each rule directly into applications.

Article 21(d) requires access restrictions on ICT assets to include controls and tools to prevent unauthorised access. For Axiomatics, this requirement translates into an architecture in which the policy and the decision are separated from the application that enforces the result.

Axiomatics relies in particular on the XACML model. When a request arrives, a Policy Enforcement Point (PEP) intercepts it and passes the necessary information to the Policy Decision Point (PDP). The PDP evaluates the policies and the available attributes, then returns a decision, typically Permit or Deny. The PEP then enforces that decision on the protected resource. Policies are administered through a Policy Administration Point (PAP) and the information needed to evaluate them may come from Policy Information Points (PIP) such as a directory, a database or another reference source.

For Claire, the application therefore does not need to contain a series of conditions such as “if Finance France, if classification X, if action Y, then allow”. It asks the authorization engine whether Claire may view FIN-2026-00452. The PDP evaluates the policy with the necessary attributes and returns its decision to the PEP.

Above all, this externalisation makes it possible to apply the same authorization policy at several points of the information system. Axiomatics documents this for applications, microservices and API Gateways; in the latter case, the gateway can act directly as the PEP while Axiomatics remains the PDP.

DORA also requires events relating to logical access control and identity management to be logged. Article 12 requires the level of detail of logs to be appropriate to their purpose and to allow, in particular, the detection of anomalous activities.

Axiomatics can contribute to this chain of evidence by logging authorization decisions. The vendor distinguishes in particular between the administrative audit of policies and the authorization logs produced at runtime, which make it possible to follow the decisions taken during access requests.

In our example, the point is therefore not only to know that Claire attempted to view a file. It also becomes possible to keep the authorization decision taken at that moment and to link it to the policy used.

This trace does not, however, replace the complete logging framework required by DORA. Article 12 also covers ICT system activities, change management, network traffic and other events. Axiomatics provides evidence of its authorization decision; the other logging and security building blocks remain necessary to reconstruct the overall activity of the system.