How authentik supports DORA ICT access controls for financial entities
DORA has applied since 17 January 2025, and Article 9 of Regulation (EU) 2022/2554 requires a financial entity to use strong authentication, to limit logical access to what approved activities require, and to keep its ICT systems under continuous control. authentik can supply much of the technical layer for that work: a single identity provider for applications using OAuth2/OIDC, SAML or LDAP, MFA enforcement set per application and group, group-based access assignment, and event logs that record sign-ins and administrative changes. It cannot make the entity compliant on its own. DORA is a regulation supervised by national competent authorities under Article 46, and it sets no certification scheme, so no product or integrator can certify a deployment against it. DeployOpen configures authentik, documents the settings and collects the evidence the entity's own assessors will examine. DeployOpen does not issue audit reports, attestations or certifications, and the entity should confirm with its supervisor which evidence it expects.
Several DORA obligations sit outside the identity platform. The information security policy, the risk assessment that sets which systems support critical or important functions, the ICT change management process, the register of information on ICT contractual arrangements under Article 28(3), and the exit strategies under Article 28(8) are governance and contract decisions that the entity owns. Access review decisions are also the entity's to make. Delegated Regulation (EU) 2024/1774 sets the review cadence (at least every six months for systems supporting critical or important functions and at least yearly for others, under Article 21), but a reviewer must still decide whether each person keeps each right. authentik can export group memberships and show when access was last changed, which gives reviewers the inputs. The reviewer's sign-off, and the records of who approved what, must come from the entity's own governance process.
Before scoping the work, the entity should confirm three points with its team. First, which edition covers the features it needs, since the pricing page places Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging in the Enterprise tier. Second, whether its supervisor or internal audit expects the authentik version to be on a supported line, using the authentik security policy as the reference for which releases receive security fixes. Third, which applications support critical or important functions, because the 2024/1774 review and testing obligations apply to those systems first. Answers to these questions determine the configuration scope and the evidence pack.
Mapping DORA Article 9 and RTS requirements to authentik capabilities
This table maps each DORA access requirement to the authentik capability that supports it and the setting to configure. Read each row as a starting point for your own control design, since the assessor will test your configured environment rather than the product's feature list. The main takeaway is that most evidence depends on configuration choices you make and record, including MFA factors and whether the Enterprise features your evidence needs are licensed.
| Requirement | authentik capability | Configuration to set |
|---|---|---|
| Article 9(4)(c): policies limiting logical access to what approved activities require | Application-level access through OAuth2/OIDC, SAML and LDAP providers, bound to groups and policies that decide who can sign in | Bind each provider to an application with a named group. Remove default access for broad groups and document the approver for each group. |
| Article 9(4)(d): strong authentication based on relevant standards | MFA stages in authentik flows for OIDC, SAML and LDAP clients. Confirm which factor types and protocol clients (such as LDAP or RADIUS) can enforce them. | Require MFA in the authentication flow for critical applications and privileged groups. Confirm the factor choice (TOTP, WebAuthn, or other) against the authentik provider documentation and your risk assessment. |
| Article 9(4)(e): protection of cryptographic keys | authentik signs OIDC tokens and SAML assertions with keys it holds in its configuration. Confirm where key material is stored in your deployment. | Store signing keys in an approved secret store, restrict database and admin access to them, and record rotation procedures. Confirm the mTLS client certificate option and any FIPS needs against the pricing page, since those are listed as Enterprise or Enterprise Plus features. |
| Delegated Regulation 2024/1774, Article 21: access rights review at least every six months for critical or important functions and at least yearly for others | Group and application membership is visible in authentik, and enhanced audit logging is listed as an Enterprise feature. Confirm what the Open Source edition exports for review. | Export membership per application on a fixed schedule, record reviewer sign-off and remove stale access. Confirm the audit logging you need against the pricing page before you choose the edition. |
| Revocation on leaver events (Article 9(4)(c) with the access rights review) | Disabling a user in authentik blocks new sign-ins to federated applications. Confirm how existing sessions and tokens are handled for each provider type. | Document the leaver procedure, test disablement against each application, and confirm token lifetimes and session termination settings in the provider documentation. |
| Article 9(4)(d): documented ICT change management and recording of access changes | Configuration changes to providers, flows and policies are made in the admin interface or as configuration code. Confirm the change record your tooling produces. | Route provider and flow changes through your change process, store exported configuration under version control, and tie each change to an approval. |
| Article 9(4) second subparagraph: segmentation of connections to critical processes | Outposts and proxy providers can sit in specific network segments in front of protected applications. Confirm supported topologies in the outposts documentation. | Place outposts in the network segment that reaches the protected application, and restrict which networks can reach the authentik admin interface. |
Configuring authentik to support DORA access controls
This sequence moves authentik from a self-managed install to a configured access layer, with each step producing evidence that maps to the Article 9 access and authentication expectations. The order matters because logging and review evidence depend on the earlier identity and group decisions.
Deploy on infrastructure the entity controls
The platform team deploys authentik in the entity's own cloud account, data center or private network, using the Docker Compose guide for a test or small-scale setup or the Kubernetes guide with Helm for a larger one. The Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM, and the Kubernetes guide says the chart's bundled PostgreSQL is for demonstration and test environments. For production, provision a separately managed PostgreSQL instance with its own backup and high availability design, and confirm that the server and worker containers both reach it. The step is complete when the admin console loads over the approved TLS endpoint and the database holds the configuration. Confirm sizing with your own load estimates and your vendor or partner, since the published minimums are starting points only.
Bind each in-scope application through a matching provider
For each application in the ICT register, the application owner and the identity team choose the provider type that the application supports: OAuth2/OIDC, SAML, LDAP, proxy, RADIUS, SCIM or others. Each application gets its own provider and application object so that access decisions, tokens and logs can be traced to a single system. Applications that cannot speak modern protocols are routed through the proxy provider rather than left with local accounts. The check for this step is an inventory table listing each application, its provider type, its owner and whether direct local login has been disabled. Any application without a confirmed provider stays on the open items list until the owner signs off.
Enforce MFA by group and application
The identity team creates authentication flows and policies that require a second factor for every user and every application within the DORA scope, and sets stricter requirements for administrative groups. Authentik's second-factor options and the exact policy bindings should be confirmed against the current documentation for the version in use, and the team should confirm with the entity's CISO whether phishing-resistant authenticators are required for privileged users under its own ICT risk policy. Test each application with a standard user, an administrator and a user without an enrolled factor. The step closes when the test log shows that every in-scope application rejects a password-only login and that exceptions, if any, are recorded with written approval.
Separate privileged accounts from everyday identities
The security team creates dedicated administrator accounts for authentik and for each in-scope application, separate from the accounts people use for email and daily work. These accounts are placed in narrow admin groups, assigned the strictest MFA policy, and excluded from the general-purpose application bindings. Break-glass accounts are created with credentials held under the entity's own custody process and tested on a schedule the entity sets. The step is done when a list of privileged accounts can be produced from authentik, each account maps to a named person, and the list matches the privileged access register the entity keeps for Article 9(4)(c) purposes.
Define group-to-role mappings aligned to least privilege
The identity owner and application owners agree on a group model in which each group grants only the application roles that a job function needs. Groups are mapped to application roles through authentik's property mappings or the application's own role configuration, and default groups are kept empty of access. The design should be written down before users are migrated, so that approvals, exceptions and reviews refer to the same model. Test that a user in one business group cannot see roles reserved for another, and record the mapping as a configuration artifact in version control where practical. The step is complete when the signed mapping document and the test results match the live configuration.
Configure deprovisioning and session limits
The identity team sets how leavers and role changes flow into authentik, either through an upstream directory, an HR-driven source or a SCIM integration, and documents the expected time from a termination decision to disabled access. Session lifetimes and idle timeouts are set in the flows and applications, with values chosen by the entity's risk assessment rather than copied from defaults. Test a disabled account against each application, including any active sessions and API tokens, and confirm that the application no longer accepts it. The step produces a test record for each application showing revocation took effect and a written list of any application that cannot be revoked centrally.
Set log retention and forwarding before the first review
The operations team configures authentik and the surrounding infrastructure to forward authentication, authorization and administrative events to the entity's central logging platform, and sets retention periods that the entity's policy and any applicable supervisor expectations require. Authentik stores its data in PostgreSQL, so the team should also confirm how database backups and log retention interact, and whether enhanced audit logging is needed for the entity's evidence requirements (the pricing page lists it as an enterprise feature, so confirm the edition with the vendor). Run a sample login, a failed login, a permission change and a disabled account through the pipeline and confirm each event appears in the central store. The step is complete when the sample events are retrievable and the first access review has a defined data source.
Schedule access reviews and patch windows
The governance team sets the review calendar for in-scope systems and the patch policy for authentik itself, using the cadence required by Delegated Regulation (EU) 2024/1774 for systems supporting critical or important functions and the entity's own policy for others. The platform team subscribes to the authentik security policy and release notes, checks which versions receive security fixes, and plans upgrades within the supported version range, since security releases are announced in advance. The first review is run from exported group and role data, and the reviewer signs off on each entitlement or records a removal. The step is complete when the review schedule, the upgrade procedure and the first signed review are filed together as evidence.
Evidence authentik produces for DORA access reviews
A DORA access review is only as credible as the records behind it. The items below are the artifacts an authentik deployment can produce, and the ones your own ICT change and documentation processes must keep. Whether they are sufficient is for your auditors and supervisor to decide, not for the platform.
Group and policy exports
Periodic exports of users, groups, roles and the policy bindings that grant access show who held which access at a given point. Use them as the baseline for each access rights review under Delegated Regulation (EU) 2024/1774, and compare each export with the approved access list for the system. Confirm with your deployment team exactly which objects and bindings a given export captures in your version of authentik, and store the export with a timestamp and the reviewer's sign-off.
Authentication and MFA event logs
Login, failed login, MFA challenge and session events show how strong authentication was applied in practice, which supports the strong authentication requirement in Article 9(4)(d). Forward these logs to your central log store and retain them under your logging policy. Check that MFA events are recorded per application, so you can show coverage for systems supporting critical or important functions, not just for the identity provider itself.
Application provider assignments
Each application connected through an authentik provider is a point where access is granted, so the list of providers and the groups bound to them is evidence of scope. Record which applications support critical or important functions and which groups can reach them. Review the list whenever a provider is added, changed or removed, and check that no application is reachable through an unmanaged path that bypasses the provider.
Version-controlled policy change records
Access policies and flow configuration kept in version control create a change history with authors, approvals and diffs. Article 9(4)(f) expects changes to be recorded, tested, assessed, approved, implemented and verified, so link each merged change to a ticket, a test result and an approver under your ICT change management policy. Confirm where your team keeps this history and that the repository itself is protected from direct edits.
Periodic access review records
The review record itself is evidence: who reviewed which access, what they decided, what was revoked and when. Delegated Regulation (EU) 2024/1774 requires access rights review at least every 6 months for systems supporting critical or important functions and at least yearly for others. Keep the signed review, the revocation tickets that followed, and the proof that revocations took effect in authentik, because auditors sample these together.
Where authentik sits in the access path and what it does not cover
authentik is the identity layer in the access path, not the whole path. According to the authentik architecture documentation, a deployment has a server container (core plus an embedded outpost), a worker container that runs background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. For DORA purposes, that means the authentication decisions, access policies, audit events and user records all live in components you host and must monitor, back up and restore. Confirm where each container runs, which network zone the PostgreSQL instance sits in, and who holds administrative access to the database. Because the database holds the access model itself, a PostgreSQL loss or corruption is an ICT availability event for every application that signs users in through authentik.
Data residency and backup of PostgreSQL therefore belong in your ICT risk assessment for authentik. Article 9(2) expects tools that keep systems resilient and available, and Article 9(1) expects data to be protected at rest and in transit. Decide where the database and its backups are stored, how they are encrypted, and how often a restore is tested against a realistic identity set. The authentik 2025.10 release notes state that authentik no longer uses Redis and moved caching, tasks, sessions and WebSocket functions into PostgreSQL, which raises the load on the database. Confirm your database sizing and connection limits with that change in mind, and plan a separately managed PostgreSQL for production, as the Kubernetes guide recommends, rather than the demonstration database bundled with the chart.
Article 9(4)(a) and the second subparagraph of Article 9(4) are carried by network controls, not by authentik. The requirement that network connection infrastructure can be instantly severed or segmented, and that affected assets can be isolated during an attack, depends on firewalls, segmentation between the identity zone and application zones, and the ability to cut off a compromised component. authentik can disable a user, revoke sessions or block a provider, but it cannot segment your network. Document which network paths reach the authentik server, worker, outposts and database, and test whether you can isolate the identity tier without taking down the directory or the applications that depend on it. The firewall rule verification and access review cadence in Delegated Regulation (EU) 2024/1774 should be scheduled against these paths, and the owners of those controls should be named in your policy.
What authentik does not cover for DORA
authentik handles identity and access controls for the systems you place behind it, but several DORA duties sit outside any identity platform. The cards below set out what remains with your team, your contracts and your testing program, and which authentik features need a paid tier before you rely on them.
ICT third-party register and exit plans
Article 28(3) requires a register of information covering every contractual arrangement for ICT services, and Article 28(8) requires documented, tested exit strategies and transition plans for services supporting critical or important functions. authentik does not produce either document. If you use a partner to deploy or run authentik, that partner belongs in the register, and your exit plan must describe how identities, provider configurations and application integrations move out. Confirm both with your compliance lead.
Contract terms under Article 30
Article 30(2) requires every ICT services contract to state where services are provided and data processed, to require advance notice of location changes, and to cover data return on insolvency or termination of the provider. These are contract clauses, not configuration. authentik stores its configuration and data in PostgreSQL in the infrastructure you choose, but the contract with any deployment or support provider must make the location and return terms explicit.
Vulnerability scanning and firewall verification
Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning of ICT assets supporting critical or important functions at least weekly (Article 10), and firewall rule verification at least every 6 months for those systems (Article 13). authentik's server and worker containers and the database are assets in that scope, but authentik does not scan them or verify your firewall rules. Your scanner, your network team and your patch records carry these duties, and the security policy page only describes how the project handles its own fixes.
Enterprise-only access controls
Privileged access management, password history and enhanced audit logging are listed on the authentik pricing page as enterprise-only features, alongside mTLS client certificate authentication and ticket-based support for subscriptions over $1k. The code in the enterprise directory is under a separate license. If your access review or privileged access design depends on these, budget for the enterprise edition and confirm current terms on the pricing page before you build the control around it.
Enterprise Plus FIPS and SLA items
The pricing page lists Enterprise Plus extras including dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Article 9(4)(d) asks for protection of cryptographic keys with encryption driven by data classification, and a FIPS-validated mode may matter for that analysis. Enterprise Plus starts at $20k annually. Ask the vendor to confirm what FIPS compliance covers in your deployment and whether it satisfies your own cryptographic standard, and do not treat the item as a DORA control in itself.
Threat-led penetration test attestation
The only authority-issued attestation DORA provides for is that a threat-led penetration test met the requirements of Article 26(7). No tool, including authentik, produces that attestation, and DORA sets no certification scheme for the platform. Plan a TLPT with the authorities or the testing provider your competent authority recognizes, and use your authentik configuration, access reviews and logs as inputs to that exercise rather than as evidence of compliance on their own.
Open source versus enterprise features for regulated access control
The decision starts with licensing. Most of the authentik repository is under the MIT license (SPDX: MIT), so most of the code can be read, modified and run under MIT terms without a subscription. Code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory, so features built there carry different terms. Have legal review both the authentik LICENSE file and the enterprise directory before the access design is fixed, because the features your controls depend on determine which license governs them.
Several controls that DORA Article 9 asks for depend on features the pricing page places in the Enterprise tier. Article 9(4)(d) calls for strong authentication based on relevant standards, and mTLS client certificate authentication is listed as Enterprise-only, so a team relying on certificates for service or device access must evaluate it. Article 9(4)(c) limits access to what approved activities require, which points to privileged access management, also Enterprise-only, for administrative accounts. Enhanced audit logging supports the continuous monitoring described in Article 9(1), and password history is relevant where password rules form part of your authentication design. Google Workspace and Microsoft Entra ID integrations are Enterprise-only too, which matters if either is your identity source. Confirm in your own risk assessment that each feature is actually required.
Pricing is published on the authentik pricing page, and the figures below reflect what that page lists, not terms agreed for your contract. The page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Ask the vendor to confirm current prices, which charges recur, whether the support tier affects your incident response obligations, and whether every feature your design requires is included in the edition you buy. Record those answers in the written scope, because a DeployOpen quote follows from it.
Questions about authentik and DORA access controls
Does using authentik make our organization DORA compliant?
No. DORA does not certify software, and no product makes a financial entity compliant. authentik supports controls that Article 9 and the related delegated regulation expect, including strong authentication, centralized access, group-based least privilege and revocation. Your organization still owns the ICT risk management framework, the policies, the risk assessments and the evidence that the controls operate. Competent authorities supervise compliance, and DORA provides no certification scheme, so treat authentik as one component of a documented control set rather than a compliance outcome.
How much does outside help for authentik and DORA cost?
DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope. The main cost drivers are the number of applications that need SSO or MFA, the number of distinct integrations (directories, HR sources, SaaS targets), whether the deployment is on Kubernetes or Docker Compose, how many environments you need, and how much evidence design is included, such as mapping controls to Article 9 and the access review records your supervisor may ask for. Ongoing support, upgrades and testing can be handled through a retainer. Ask any provider for a line-item quote that separates one-time build work from recurring operations, and confirm who performs the access review workshops.
How long does authentik access control configuration take?
The duration depends on scope and on how quickly your organization signs off decisions. A small set of applications with one directory and a clear group model moves much faster than a program covering many critical or important functions, several HR systems and a formal review cycle. The slowest steps are usually not technical: agreeing the group and role model, approving MFA rules per application, and getting the leaver process mapped to account disablement. Ask the provider to break the schedule into discovery, build, testing, cutover and evidence handover, and to name the approvals required at each gate before work starts.
What must our organization provide before an authentik engagement starts?
Prepare four inputs before the build begins:
- An application inventory listing each system, its owner, whether it supports critical or important functions, and the protocol it can use (OIDC, SAML, LDAP or a proxy approach)
- A group and role model that describes who needs which access and who approves it
- An HR leaver and mover process with named systems of record and a target time for removing access
- Staff with time for access reviews, including application owners who can confirm whether each user still needs access
Without these inputs, the work tends to stall at design. Confirm the inventory against your ICT asset records and your register of ICT third-party arrangements.
Can our own team set up authentik for DORA controls without an outside partner?
Yes, if your team has the skills and capacity. authentik is open source under the MIT license for most of its code, and the core deployment is documented for Docker Compose and Kubernetes. The harder work is not installation. It is designing policies that match your risk assessment, configuring MFA and session rules per application, testing revocation, building review evidence and keeping the system patched on a documented schedule. Enterprise-only features, such as enhanced audit logging and privileged access management, are sold on separate terms, so check the license and feature list before you rely on them. Many teams split the work: internal staff own the policies and reviews, and a partner builds or tests the integration.
Which authentik version should we target for a DORA deployment?
Target a version on a supported line. The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. The GitHub releases page shows 2026.8.4, published on October 14, 2026, as the latest release at the time of this research. Pick the line that fits your upgrade calendar, pin the exact version in your change records, and plan upgrades as documented changes that are tested and approved, as Article 9(4)(f) expects. Confirm the current release and any breaking changes on the release notes before you start, because the project's upgrade rules are sequential.
Does authentik support the weekly and six-monthly review cycles DORA expects?
authentik can hold the group membership, application assignments and event records that reviews depend on, but it does not run your review process. Delegated Regulation (EU) 2024/1774 sets access rights review at least every six months for systems supporting critical or important functions and at least yearly for others, and it requires automated vulnerability scanning weekly for those assets. Those scans are not an authentik feature. Set up review reports from group and application data, assign reviewers, and keep signed outcomes. Confirm with your supervisor and internal audit how they want review evidence presented before you design the reports.
How DeployOpen scopes and delivers DORA access control work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik, that means turning the access control requirements a financial entity has to meet into a written scope, a tested build and evidence the entity's own teams and assessors can read.
How we scope
- Agree in writing which systems supporting critical or important functions authentik will front, and which stay out of scope.
- Map each access requirement to a named configuration, owner and evidence source before any build starts.
- Confirm which authentik edition and features the design needs, such as enterprise-only options, from the current pricing page.
How we build
- Deploy authentik in your infrastructure with the database, worker and reverse proxy design agreed during scoping.
- Configure MFA enforcement, group-based application access, session limits and revocation paths, then test each one against the written requirements.
- Run access and firewall verification steps as scheduled checks, and document the results alongside the configuration.
How we hand over
- Deliver configuration as code, runbooks for joiners, movers and leavers, and the access review procedure your staff will run.
- Document the evidence each control produces, where it is stored and how long your retention policy keeps it.
- Walk your operations, security and compliance teams through the handover and record what they have accepted.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope delivery ends.
- Plan authentik version upgrades against the supported release lines published in the security policy, with notice before changes.
- Ask your compliance function to confirm which assessor, supervisor or internal audit will review the evidence, since DeployOpen does not issue attestations.
