Why authentik for financial services fits a self-hosted identity layer
Self-hosted authentik fits regulated finance when the identity layer must run inside infrastructure the institution controls, and the build changes in three places: the deployment sits in the institution's own cloud accounts or data centers, the enterprise features that finance teams usually need are priced and licensed separately, and the evidence for each control must be produced by the institution's own systems. A finance identity lead typically faces the same questions from several directions at once: which privileged accounts lack a second factor, who approved a standing admin role, and whether leavers lost access on the day they left. Under DORA, PCI DSS and SOX, those questions arrive as requests for the register of ICT arrangements, the cardholder environment scope, and the ITGC evidence for access to programs and data.
Self-hosting matters for those requests because DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed. Running authentik in the institution's own environment keeps user directories, session data and audit logs in locations the institution can name and defend, and PostgreSQL holds all configuration and data except uploaded files, so the database location is the first thing to document. Note that the open-source edition does not include privileged access management, password history, enhanced audit logging or mTLS client certificate authentication, which are Enterprise features on the authentik pricing page. Confirm with authentik which of these you need before you finalize the architecture, because finance teams usually cannot accept a gap in privileged access or audit logging. DeployOpen plans, implements and documents authentik inside your infrastructure, including the MFA configuration, access request and review workflows, and offboarding evidence your auditors will ask for. DeployOpen does not issue audit reports, attestations or certifications. Your internal audit function, your Qualified Security Assessor or your competent authority decides whether the controls satisfy your obligations, so the first deliverable to agree in writing is the list of controls and the evidence each one produces.
Which financial services requirements shape the authentik build
This table maps each financial services requirement in scope to what it asks for, the evidence an assessor or supervisor will expect, and the authentik configuration, logging or contract work it implies. Read each row as a design input: the requirement comes first, then the build decision it forces. Several rows point to contract terms and exit planning, which sit outside authentik itself but determine how the identity platform can be governed.
| Requirement | What it asks for | Build implication for authentik |
|---|---|---|
| DORA Article 28(3) | A register of information covering all contractual arrangements for ICT services | Record authentik as an ICT service in the register, including the self-hosted scope, the vendor support terms and any Enterprise subscription, with the named owner for each component. |
| DORA Article 28(8) | Documented, tested exit strategies and transition plans for ICT services supporting critical or important functions | Treat identity as a critical dependency: plan how applications would authenticate during an exit, keep configuration exportable and test restoring the PostgreSQL database to a second environment. |
| DORA Article 30(2) | Contracts that state where services are provided and data processed, advance notice of changes, and data return on termination or insolvency | Confirm with the vendor and your legal team where any support access, telemetry or license checks occur, and specify data return terms for user records and audit logs held outside your infrastructure. |
| PCI DSS v4.0.1 access requirements | Controls over who can reach systems in the cardholder data environment, with unique IDs, strong authentication and periodic review | Scope authentik as an access control point for the cardholder data environment, enforce MFA on administrator and remote access, and export group membership for quarterly reviews. Confirm assessor expectations with your QSA. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | MFA for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing | Enforce a second factor in the authentik authentication flow for all user populations, including LDAP and RADIUS clients where supported. Record any written exception and the compensating control in the risk file. |
| SOX ITGC access areas (SEC Release 33-8810) | Access to programs and data as an IT general control area relevant to ICFR assessments, alongside program change and computer operations | Keep group and role assignments, admin privilege grants and provider changes under change control, and retain audit events for administrative actions. Auditors will test whether approvals match recorded changes. |
| Swift CSCF v2026 | 32 controls (26 mandatory, 6 advisory) assessed independently, with annual attestation in the KYC-SA application | Map the identity controls to the relevant Swift controls for your architecture, identify which are mandatory for your role, and ask your assessor which evidence from authentik they will sample. |
| Audit logging and retention | Evidence that access events can be reconstructed, which assessors commonly request for privileged and remote access | Enterprise pricing lists enhanced audit logging, so confirm whether the events you need are available in your edition. Forward logs to a store you control and set retention to match your contract and regulatory period. |
Which authentik modules and settings matter for banks and insurers
A financial institution rarely needs every authentik feature on day one. The cards below cover the provider types, authentication controls, administrator access and audit settings that usually shape a banking or insurance design. Several of these controls sit in the Enterprise edition, so each one needs a fit check against your requirements before the scope is written.
OAuth2, OIDC and SAML providers
Core banking front ends, workforce portals and reporting tools usually need OAuth2/OIDC or SAML. Map each application to one provider type, record its redirect URIs, token lifetimes and attribute mappings, and confirm which claims the application actually reads. Review every provider as part of the application inventory your regulator or auditor will ask for.
LDAP and RADIUS for legacy clients
Older teller systems, network devices and Wi-Fi or VPN clients often speak only LDAP or RADIUS. These protocols carry different MFA behavior than OIDC, so confirm which second factor, if any, each legacy client can enforce. Isolate these providers to the networks that need them and record the exceptions in your access review.
MFA enforcement and phishing-resistant options
Set MFA through authentication flows and policies so it applies to every workforce login, not only to some applications. Ask whether hardware-backed options such as passkeys or security keys meet your phishing-resistance standard, and document the fallback for lost devices. Keep the enrollment and recovery path under the same written control as the login path.
Privileged access and RAC for administrator sessions
Administrator access to core systems should go through a controlled path with approval and recorded sessions. authentik's remote access control provider and privileged access management are Enterprise-only features on the pricing page, so confirm they cover your administrator workflow. Check how sessions are recorded and where those records are stored.
Audit logging and retention
Enhanced audit logging is listed as an Enterprise feature, while the standard event trail is available in every edition. Define what events your access reviews and incident investigations need, such as logins, policy changes and admin actions, then confirm the retention and export path. Forward these logs to your SIEM and test that they survive an upgrade.
Enterprise-only mTLS and password history
Client certificate authentication (mTLS) and password history are listed as Enterprise features on the pricing page. Use mTLS for machine or branch connections where your policy requires it, and password history where local passwords remain in use. Confirm both features against your written control text and your edition choice before you budget the project.
How authentik's server, worker and PostgreSQL layers sit in regulated infrastructure
A regulated deployment of authentik has three runtime layers to place and govern: the server container, which runs core plus an embedded outpost, the worker container, which handles background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. According to the authentik architecture documentation, PostgreSQL is the single data store, so the database is where your evidence, audit trail and user records live. Decide early which network zone hosts each layer, who holds administrative access to the database, and how the database is backed up and restored inside the boundary you already audit. Confirm with your own platform team whether the embedded outpost can reach every application segment that needs it, or whether separate outposts will be required in segmented networks.
The 2025.10 release removed Redis entirely, moving caching, tasks, sessions and WebSocket functions onto PostgreSQL. The release notes warn of roughly 50% more PostgreSQL connections after upgrading, so connection planning becomes a capacity decision rather than a cache decision. Size the connection limit, any pooler in front of the database, and the failover behavior together, and test a login spike and a worker backlog against that database before go-live. For a bank or insurer, the same database also carries session state, so a database outage is an authentication outage. Plan its high availability and recovery objectives as part of the identity service, not as a separate infrastructure ticket.
Deployment method sets how much of this you must build yourself. The Docker Compose guide positions Compose for test setups and small-scale production, with a minimum of 2 CPU cores and 2 GB of RAM, which suits a pilot in a non-production zone. The Kubernetes guide installs with Helm and says the chart's bundled PostgreSQL is for demonstration and testing, recommending a separately managed PostgreSQL for production. In a regulated estate, that usually means a database service you already operate under your existing controls. Data residency and exit planning then follow from where that database runs: confirm the jurisdiction of every host, backup copy and log store, and document the export path, since DORA Article 28(8) expects tested exit strategies for ICT services that support critical or important functions.
How a financial services authentik rollout runs in phases
The sequence moves authentik from agreed control requirements to a tested, evidenced and handed-over identity service inside your own infrastructure, with each phase closing on a check your risk and audit teams can review. Durations for each phase are set in the written, fixed-scope plan.
Scope applications and map identity controls
DeployOpen and your identity, security and compliance leads agree which applications, user populations and privileged systems are in scope, then map each access control to the requirements that apply, such as PCI DSS, DORA ICT third-party expectations, SOX IT general controls or FTC Safeguards MFA duties where they apply to you. The output is a written scope and a control map that names the evidence each control will produce. Confirm with your own counsel and assessor which frameworks bind your entity before this step closes.
Build a non-production instance in your infrastructure
The team deploys authentik into a non-production environment in your cloud account, data center or private network, using a PostgreSQL service you manage, with the server and worker containers, reverse proxy, secrets handling and backup configuration defined as code. Confirm early whether your Kubernetes or Docker standard applies, because the chosen platform changes sizing and operations. The step closes when a test login succeeds end to end and a restore from backup has been demonstrated.
Pilot MFA and privileged access requests
A limited group of workforce users and administrators is enrolled in the chosen second factors, and privileged access requests are routed through approval flows with recorded justification and time limits where your policy requires them. Confirm with your security team which phishing-resistant factors and which privileged access features are available in the edition you license, since some capabilities are Enterprise-only. The pilot closes when enrollment, recovery and approval records are reviewed and accepted by the control owner.
Cut over applications in controlled waves
Applications are moved to authentik in waves, starting with lower-risk internal tools and ending with payment, core banking or customer-facing systems that need a documented rollback path. For each application, the team tests the protocol configuration, group-to-role mapping, session behavior and fallback access, and records the change under your change management process. The wave closes when each application has passed functional tests, its rollback has been rehearsed, and the change record is filed.
Prove access reviews and offboarding evidence
The team runs a sample access review cycle and a joiner, mover and leaver test, producing exports of group memberships, approval history, audit log entries and deprovisioning timestamps in a form your auditors can sample. Where directories or SaaS applications are provisioned from authentik, the team confirms that revoking access in authentik removes or disables it downstream. The step closes when your reviewer signs off on the evidence pack and any gaps are logged with owners and dates.
Hand over operations and the exit plan
DeployOpen hands over runbooks for monitoring, backups, upgrades, outpost maintenance and incident response, together with the configuration repository, the register entries for the service and the documented exit and transition plan your third-party risk process requires. Your operations staff run a supervised change, such as a version update, so they have practiced the procedure before support moves to your team or a retainer. The handover closes when your operations owner accepts the runbooks and the register entry is updated.
What authentik can evidence for PCI DSS, DORA and SOX and what it cannot
Identity controls feed several frameworks at once, but each framework asks for different proof and assigns the judgment to a different party. The cards separate what an authentik deployment can record from what an assessor, auditor or competent authority must decide.
MFA and access control logs
authentik's event log can show which users signed in to which applications, and which second factor or flow step they passed. For PCI DSS and the FTC Safeguards Rule, this is the raw material for showing that MFA covers every administrative and remote path into the cardholder environment. Check that logs are exported to your retained log store, because the in-product record alone rarely satisfies an assessor's retention questions.
Enterprise audit logging
Enhanced audit logging is listed as an Enterprise-only feature, so the depth of change history you can show for SOX and PCI DSS reviews depends on the edition you buy. Confirm with the vendor which events, fields and retention are included in the edition you license before you rely on them as evidence.
Access reviews and offboarding evidence
authentik can show the current groups, applications and policy bindings for each user, but a periodic access review is a business control that someone must perform and sign. Build the review around exported group membership, record the approver and decision, and tie disablement to HR or ticket events so that offboarding leaves a traceable chain.
DORA register and exit strategy inputs
Article 28(3) requires a register of information on ICT contractual arrangements, and Article 28(8) requires tested exit strategies for services that support critical or important functions. authentik's open-source licensing and self-hosted architecture give you the component list and data location to document, but the register entry, contract terms and exit tests remain your obligations. Record where PostgreSQL, the server and worker containers run, and who holds the Enterprise subscription if you use it.
PCI DSS scope reduction through SSO
Placing cardholder data environment applications behind SSO can narrow which administrative paths and user accounts an assessor must examine, but it does not remove systems from scope by itself. Scope depends on whether any component stores, processes or transmits cardholder data or could affect its security, so the identity provider and its database may themselves be in scope. Ask your QSA to review the network and data flow diagrams before you describe any reduction.
Assessments and attestations stay with third parties
A Qualified Security Assessor issues a Report on Compliance, and the payment brands decide who must validate. DORA's only authority-issued attestation concerns threat-led penetration testing, and SOX conclusions come from management and external auditors. DeployOpen prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications. Separately, confirm your Swift Customer Security Controls Framework status with your own assessor, since it is a distinct attestation.
Choosing between Open Source, Enterprise and Enterprise Plus for finance
The edition decision for a financial services deployment comes down to which controls must be in place on day one and who is responsible for them. The authentik pricing page lists three editions: Open Source, which is free and supported through the community Discord only, 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-only features named on that page include privileged access management, enhanced audit logging, password history, mTLS client certificate authentication, and the Google Workspace and Microsoft Entra ID integrations. For a bank or insurer, privileged access management and enhanced audit logging are the features most likely to map to access request and access review evidence, so confirm early whether your control design depends on them. Confirm current prices with the vendor, since the pricing page is the source and figures change.
The license split matters for the same review. Most of the repository is under the MIT license (SPDX: MIT), while code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory. Your legal and procurement team should read that license text directly, and should confirm how the enterprise directory applies to your intended use, including self-hosting inside regulated infrastructure. Enterprise Plus extras listed on the pricing page include dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Only add Enterprise Plus if you have a written requirement for one of those items, because the entry price is the largest fixed cost in the comparison.
Tie the edition to the written scope rather than to a feature wish list. List each control your DORA, PCI DSS or SOX evidence plan needs, mark which ones require an Enterprise feature, and ask for a quote that prices those licenses against your user count, external user count and support needs. Ask the vendor to state in writing which features are included in each edition and how licensing counts users, since the per-user and per-external-user terms drive the recurring cost. A quote built this way lets your team compare the subscription against the internal effort of building equivalent controls on the open-source core.
Questions finance teams ask before hiring an authentik partner
What drives the cost of an authentik build for a regulated financial firm?
The scope written into the engagement drives the cost more than anything else. The main components are discovery of your applications and identity sources, the target architecture and hosting design, provider and flow configuration for each application, MFA and privileged access setup, testing, runbook and evidence preparation, and handover. Software licensing is a separate line. authentik's Open Source edition is listed as free on the authentik pricing page, while Enterprise is priced per user, so the number of users and the Enterprise features you need will change the licensing cost. Ask any partner for a quote that separates one-time build work from recurring support, upgrades and testing, and that names which features require Enterprise.
How long does a regulated authentik build take, and what sets its length?
Duration depends on how many applications must be onboarded, how many identity sources must be connected, and how much evidence your assessors need. Each application that uses a different protocol (OAuth2/OIDC, SAML, LDAP, proxy or RADIUS) adds integration and testing work, and legacy systems that cannot speak modern protocols usually take longer. Change control, environment approvals and the availability of your own staff for reviews also add time. A partner should give you a timeline only after the written scope is agreed, and should show which milestones depend on your team's decisions.
What must our team provide before a partner starts work?
Expect to provide access to the target hosting environment, a list of applications with their protocols and owners, the identity sources you will keep (such as an HR system or an existing directory), and the MFA policy your risk team has approved. You will also need named approvers for access requests, the privileged account inventory, logging destinations and a decision on the database that will hold all authentik data. Under DORA, your register of ICT contracts and exit plans may also need the hosting and data location details, so have those documents ready. Agree the list of inputs in writing so that delays are visible early.
Can our internal engineers run authentik without an external partner?
Yes, many teams operate authentik with internal staff, provided they have people who can manage containers or Kubernetes, PostgreSQL, reverse proxies, certificates, backups and upgrades. The authentik Docker Compose guide positions Compose for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. A partner is most useful for the design, the first build, the evidence pack and the first upgrade cycles. Decide who owns each run task (on-call, identity administration, patching, restore testing) before you decide between in-house and external support, because an unowned task becomes an audit finding.
Which Enterprise features might a financial firm need, and why?
The authentik pricing page lists Enterprise-only features including privileged access management, enhanced audit logging, password history, mTLS client certificate authentication, and Google Workspace and Microsoft Entra ID integrations. Privileged access management and enhanced audit logging are often the first to be assessed against access control and logging expectations, so confirm how each one maps to your requirements before choosing an edition. The pricing page also lists Enterprise Plus extras such as dedicated support with SLAs and FIPS compliance for FedRAMP requirements, which matter if your environment has those needs. Verify current feature availability directly with authentik, because editions can change.
How do authentik upgrades and the sequential rule affect a regulated estate?
authentik upgrades must follow the documented sequential path, so you cannot skip releases, and each step needs testing before it reaches production. Security support is limited to the versions named in the authentik security policy, and the project announces security releases at least 24 hours in advance, so your change calendar must allow for short-notice patching. Release notes can include changes that affect operations, such as the 2025.10 move away from Redis to PostgreSQL, which increased PostgreSQL connections. Outposts and PostgreSQL major versions need to be planned alongside the core upgrade. Ask a partner how they will test each step and record the change for your change advisory board.
What can a partner certify, and what can it only prepare?
A partner can design, configure, test and document controls, and can prepare evidence such as configuration exports, access review records, offboarding logs and runbooks. A partner cannot issue audit reports, attestations or certifications. For PCI DSS, assessments are completed by a Qualified Security Assessor or through a Self-Assessment Questionnaire, each with an Attestation of Compliance. For DORA, supervisors assess compliance, and the Regulation provides no certification scheme. For SOX, auditors test internal controls over financial reporting. Your internal risk, compliance and audit functions remain responsible for deciding whether the controls meet your obligations.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including authentik for financial services. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which applications, user groups and privileged systems authentik will protect and which regulations apply to each.
- Record the protocols, MFA methods and LDAP or RADIUS clients in writing before any build begins.
- Agree in writing which evidence exports, access review outputs and offboarding records the scope will produce.
How we build
- Install authentik in your own cloud accounts, data centers or air-gapped networks, with PostgreSQL managed to your standards.
- Configure phishing-resistant MFA, privileged access request flows and group-based access aligned to your approved design.
- Test sign-in, MFA enforcement, deprovisioning and logging against documented test cases before go-live.
How we hand over
- Deliver configuration documentation, runbooks and a record of test results that your team and auditors can review.
- Document data location, backup and restore procedures and the upgrade path for your running deployment.
- Train your administrators on access review and offboarding evidence so your team can run them without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Plan authentik version upgrades around the supported release lines your team confirms with the project.
- Note that DeployOpen prepares systems and evidence but does not issue audit reports or attestations, which independent assessors provide.
