DORA has been in force across the EU since early 2025. The grace period that wasn't really a grace period has expired. Audits have been running for months. The patterns that show up in findings reports are starting to repeat.

Let’s talk about where DORA puts pressure on a typical AD authentication architecture, and how SystoLOCK responds. It assumes you have read the regulation, or that you have a compliance team that has read it for you. The interesting question is no longer what DORA says. It is what an estate has to look like to survive the audit.

A trader's account is flagged as suspicious. The incident-response window is short: DORA major-incident reports go to the supervisor in hours, not days, and the report has to include what the account did. The first question every analyst asks is the same: where did this account authenticate in the last eight hours, with what factor, from what device?

On a typical AD estate, the answer takes hours to assemble. Windows event logs on dozens of servers, Entra sign-in logs, VPN logs, jump-host logs, application logs from the trading platform. Each in a different format. Some with the user's UPN, some with SAMAccountName, some with an internal identifier that needs translation. The clock is running.

With SystoLOCK in the path, every authentication produces a structured event tied to the AD principal, with the factor used and the step-up status recorded. The trail is single-sourced because it goes through the SystoLOCK broker, not because Windows event logs have suddenly become coherent. The audit narrative is constructible inside the incident window, not after it.

DORA expects the strongest control where the risk is highest. In a financial entity, that is the privileged path: admins of the payment switch, the trading system, the core banking ledger, AD itself. Most estates have MFA at the perimeter and a password on the inner privileged path: the auditor's finding writes itself.

SystoLOCK does not distinguish privileged from regular authentication at the protocol layer. The same factor model protects an admin's interactive logon, their runas invocation, their PowerShell remoting session, their RDP into the jump host. There is no path where the protection silently degrades to a password. Step-up policies can require an additional factor for the highest-risk operations, but the baseline is uniform across the matrix.

This matters less as a feature than as a closure: the auditor cannot find a privileged path where the credential is weaker than the perimeter MFA, because that path is not in the deployment.

Cloud-dependent MFA is fine until the cloud is unreachable. For a financial entity that has to keep settling transactions during an outage, the resilience question on the authentication path is structural. The RTS makes this visible to the audit. A "we have a failover plan" answer is not the same as an architecture that does not need one.

SystoLOCK runs on-premises, in the same domain it authenticates against. There is no cloud service in the authentication path at all. When Entra is down, when the WAN is down, when the cloud-MFA vendor has its own incident, authentication continues. This is not a high-availability claim or a disaster-recovery story. It is a property of where the system sits.

A third party's engineer needs access at 02:00 because something is broken. DORA's third-party regime expects that engineer's authentication to be subject to controls at least as strong as the financial entity's own. In practice, this usually means either the entity issues credentials and factors to vendor staff, or the entity inherits the vendor's MFA story and audits it. The second option is harder to defend.

SystoLOCK can issue factors to vendor accounts under the same controls as employee accounts, with the same audit trail and the same lifecycle. There is no parallel identity system, no separate MFA broker, no contractual workaround. The auditor's question about third-party authentication has the same answer as the question about employee authentication, because it is the same answer.

Every regulated estate has break-glass accounts. The local administrator on the domain controller. The emergency access account in case AD itself is unreachable. The vendor-support account that documentation says only the on-call engineer should know about. DORA's identity-lifecycle expectations make these accounts visible: who can use them, how is the use monitored, what is the recovery story when the last person who knew the credentials leaves.

This is the one place where SystoLOCK does not have a clean answer for every variant. The product supports passwordless break-glass with factor custody, where the factor sits in a sealed envelope or a vault, and the audit event is the same as for any other authentication. But the genuine "AD itself is broken" scenario still needs an emergency-access path outside SystoLOCK, because anything in SystoLOCK's scope is by definition unavailable in that scenario. The honest position is that SystoLOCK reduces the surface where passwords exist by a large margin, but a small residual remains by design, and a credible auditor will expect to see it documented and managed accordingly.

DORA's effect on the authentication conversation is that "we have MFA" no longer survives a serious audit. The auditor asks where in the estate the MFA is, what kind, and what happens at the paths where it isn't. For an on-prem AD estate carrying critical functions, SystoLOCK is the only product we know of that lets every answer to that question be the same.

NIS2 was the warm-up. DORA has the shorter patience.