Open source SSO for financial services: why the identity provider becomes a regulated system
A self-hosted identity provider in a financial firm is not just an IT service. Once it issues the logins that reach customer data, payment systems or ICT services supporting critical functions, it falls inside the scope of several regulations at once. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing (16 CFR 314.4(c)(5)). PCI DSS requires MFA for access into the cardholder data environment, and DORA (Regulation (EU) 2022/2554) treats the ICT services behind login as part of its third-party and operational resilience obligations. The identity provider therefore has to produce evidence for all three, not only work.
Keycloak and authentik both cover the core workforce SSO job: OpenID Connect, OAuth 2.0 and SAML 2.0 for applications, and MFA and passkey options that you must configure and verify yourself. Keycloak is an Apache-2.0 project with broad protocol and directory federation support, including LDAP and Active Directory. authentik is MIT-licensed at its core, but features such as privileged access management, mTLS client certificate authentication and enhanced audit logging sit in its separate enterprise license, so you should confirm exactly which features your regulators and internal controls require before you commit. The right choice depends on the protocols your applications need, the directories you must federate and a license review by your legal team, not on a general ranking.
Which financial regulations set the SSO requirements and what each means for the build
This table maps each financial regulation or framework to the SSO requirement it creates and the build consequence for a self-hosted identity provider. Read each row as a question to settle with your compliance lead before design starts. The main takeaway is that MFA scope, activity logging and provider contract terms shape the identity platform as much as the protocol choice does.
| Regulation or framework | What it asks for the SSO build | Build consequence |
|---|---|---|
| FTC Safeguards Rule, 16 CFR 314.4(c) | Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing under 314.4(c)(5). Monitoring and logging of authorized user activity. | Enforce MFA on every workforce application and administrative console, not only on the front door. Keep the written approval for any exception and log sign-ins, failures and privileged actions in a form you can review. |
| PCI DSS v4.0.1, Requirement 8 (MFA into the cardholder data environment) | MFA for all access into the cardholder data environment, applied per access path, and MFA systems protected against replay and bypass. Confirm the exact sub-requirements with your Qualified Security Assessor. | Route every path into the cardholder data environment, including remote and administrative access, through the identity provider or a documented MFA gate. Test that MFA cannot be skipped through legacy protocols or local accounts. |
| DORA, Articles 28(3) and 28(8) | A register of information on all ICT contractual arrangements, and documented, tested exit strategies and transition plans for ICT services that support critical or important functions. | If the identity provider supports a critical function, record it in the register, document how users and applications would move to another provider, and test that exit path before you need it. |
| DORA, Article 30(2) | Each ICT services contract must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. | For a hosted or managed identity service, collect data location, subprocessor and data return terms in writing. For a self-hosted build, record where the identity database, backups and logs reside, including any partner access. |
| DORA, Article 26(7) and TLPT | The only authority-issued attestation DORA provides for is that a threat-led penetration test met requirements. DORA sets no certification scheme. | Scope identity infrastructure, administrative consoles and federation endpoints into penetration testing plans. Do not describe any test as a DORA certificate. |
| Swift Customer Security Controls Framework v2026 | 32 controls, 26 mandatory and 6 advisory, assessed independently and attested annually in the KYC-SA application for Swift users. | Where Swift connectivity is in scope, map which controls depend on administrator and operator authentication. Confirm with your assessor which identity controls apply to your Swift environment. |
| SEC guidance on ICFR (Release 33-8810), access to programs and data | Access to programs and data is an IT general control area relevant to Section 404 assessments of internal control over financial reporting. | Export role assignments, access reviews and administrator change logs from the identity platform as evidence for general IT controls. Confirm the evidence format with your external auditor. |
Which open-source identity platforms fit financial workloads and why
Financial institutions need MFA, audit evidence and directory integration that hold up under examination. The three platforms below differ in license terms, feature gating and operating model, so the choice depends on which controls you must prove and which features sit behind a paid edition. Each card names the decision to make before you commit.
Keycloak as the baseline option
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory user federation for existing workforce directories. Its supported production databases include PostgreSQL 14 to 18, Oracle Database and Microsoft SQL Server, so you can often reuse a database platform your DBAs already run. The Keycloak Operator supports Kubernetes deployments, and Red Hat build of Keycloak is available as a supported distribution if your organization needs a vendor support contract. Confirm that the database and high availability design meet your resilience targets before selecting it.
authentik for fast application onboarding
authentik is MIT licensed for most of its code, but the authentik/enterprise directory uses a separate enterprise license, so license review must cover that boundary. Privileged access management, mTLS client certificate authentication, password history and enhanced audit logging are listed as enterprise-only features, and some of these may be required for PCI DSS or FTC Safeguards evidence. Since 2025.10, authentik runs on PostgreSQL alone without Redis, which simplifies the stack but increases PostgreSQL connection count after upgrade. Plan connection pooling and capacity tests before go-live.
ZITADEL to evaluate for passkeys
ZITADEL is licensed under AGPL-3.0, and its README lists FIDO2 and WebAuthn passkeys, SCIM provisioning, SAML 2.0 and multi-tenancy. These features matter if you plan phishing-resistant authentication for staff and need SCIM to deprovision accounts when people leave. AGPL-3.0 carries network-use source disclosure obligations for modified versions, so have legal counsel confirm that the terms fit your internal deployment and any customer-facing portals. Test passkey enrollment, account recovery and directory sync with your own identity sources before choosing it.
Confirm licensing against required features
The license and the feature set decide the total cost and the compliance story. Keycloak's Apache-2.0 license imposes no commercial feature gate on the core product, while authentik places some capabilities behind an enterprise license and ZITADEL's AGPL-3.0 terms apply to network-accessible modifications. Build a feature matrix listing each MFA method, directory connector, audit log and privileged access requirement, then mark which platform provides it under the license you would actually use. Ask any vendor or partner to show this mapping in writing.
How phishing-resistant passkeys and privileged access fit into financial SSO
Administrators, payment operators and treasury staff need stronger authentication than a password plus a one-time code because they hold the most dangerous permissions in the environment. A phishing-resistant factor such as a passkey or WebAuthn security key binds the login to the genuine site, so a convincing fake login page cannot capture a reusable credential. Keycloak and authentik both document WebAuthn support, and ZITADEL's README lists FIDO2 and WebAuthn passkeys. Before you commit, confirm in the exact version you plan to run which WebAuthn or passkey flows are available, whether they can be enforced for a named role or group only, and how account recovery works when a key is lost, since a weak recovery path can reintroduce the phishing risk.
For the most sensitive access, you can layer certificate-based authentication on top. authentik lists mTLS client certificate authentication as an enterprise-only feature, so confirm the license tier and the license terms in the authentik/enterprise directory before you design around it. In Keycloak, the usual approach for separating privileged staff is a dedicated administrative realm with its own users, its own MFA policy and its own clients, kept apart from the customer-facing or everyday workforce realm. Verify how client authentication and realm-level admin rights are configured in your Keycloak release, and test that a staff account in the workforce realm cannot reach administrative consoles or payment back-office applications.
Identity controls do not replace privileged session recording. Recording what an administrator or vendor engineer typed or viewed on a database, server or Kubernetes cluster, and approving that session in advance, usually requires a privileged access management product, which this SSO design does not provide on its own. Decide early which systems need recorded sessions, who approves access, and how the identity provider's audit logs will be retained and correlated with PAM logs for your assessor. Ask any implementation partner to show the admin realm configuration, the MFA enrollment flow for privileged users and the audit evidence produced in a test run.
How a financial firm rolls out SSO in phases without breaking payment operations
The sequence moves identity from low-risk applications to the cardholder data environment and privileged access, producing evidence at each stage so payment operations keep running and assessors can trace every control.
Scope applications and map regulatory obligations
The team inventories every application, directory and access path, then tags each one by regulation: FTC Safeguards Rule MFA, PCI DSS Requirement 8 for systems in or connected to the cardholder data environment, and DORA controls for ICT services supporting critical or important functions. Compliance and security leads sign off the scope in writing. Done means a scoped application register with protocol (SAML or OIDC), owner, data class and regulatory tag for each entry, plus a list of applications that cannot do SSO at all.
Design the reference architecture and choose the database
Architects select Keycloak or authentik against the protocol and passkey requirements from the register, then set the topology, including whether the deployment is a single cluster across availability zones. Keycloak requires a synchronously replicated database for its supported high availability designs, and authentik stores all configuration in PostgreSQL. Done means an approved architecture diagram, a database decision, and a written list of what the identity provider must reach and what must reach it.
Pilot with applications outside the cardholder data environment
The first wave covers internal, non-CDE applications chosen for low risk and clear owners. The team tests login, session expiry, group mapping, logout and the fallback path when the identity provider is unavailable. Done means a pilot report listing each application, test results, defects closed and a sign-off from the application owner.
Run MFA and passkey enrollment in waves
Staff enroll in groups rather than all at once, starting with administrators and users who reach sensitive systems. The team confirms phishing-resistant options such as passkeys or WebAuthn where the chosen platform supports them, and documents any approved equivalent control in writing for accounts that cannot use them. Done means enrollment rates per wave, a helpdesk runbook for lost devices, and a recorded exception register.
Cut over the cardholder data environment and privileged access
Applications that touch cardholder data move to SSO only after the earlier waves are stable, with a rollback plan that keeps the previous login path available for a defined window agreed in advance. Privileged and vendor accounts go through MFA-protected access with unique user IDs and logged sessions. Done means a change record, a tested rollback, and an access review confirming that shared and generic accounts are removed or controlled.
Harden and capture audit evidence
The team applies production settings, restricts admin consoles, enables audit logging and metrics, and exports realm, client and policy configuration for assessors. Evidence is mapped to the PCI DSS Requirement 8 controls, FTC Safeguards Rule MFA and DORA register entries. Done means an evidence pack with configuration exports, log samples, enrollment records and the mapping to each regulation, ready for the independent assessor or auditor to review.
Hand over operations with upgrade and patch controls
Operating the platform after go-live is the run phase, where the Keycloak Operator's recommendation for manual approval of operator updates, schema migration handling and upgrade testing in a non-production environment belong. The handover includes runbooks, on-call ownership and a test schedule for each release. Done means a signed run book and a documented upgrade procedure that the client's team can execute.
What auditors and regulators ask to see from the identity layer
This table maps the evidence that financial services assessors and regulators commonly request from the identity layer to the component that produces it and the rule it supports. Treat each row as input for the auditor, not as a certification, and confirm the exact format each assessor or supervisor expects before the assessment starts.
| Evidence item | Produced by | What it supports | Where it usually falls short |
|---|---|---|---|
| MFA policy export for workforce and privileged logins | Keycloak authentication flow and required-action configuration exports, or authentik flow and stage bindings | FTC Safeguards Rule MFA for any individual accessing an information system, and PCI DSS 8.4 MFA into the cardholder data environment | Exports show the policy but not which users were actually enrolled, and exceptions approved outside the system are not recorded |
| User-to-application access records | Keycloak client and role mappings, authentik application and group assignments, reviewed with the identity governance process | Unique user identification and least privilege for cardholder data environment and critical systems | Shared accounts or group-based grants that cannot be traced to a named person |
| Authentication and administrative audit logs | Keycloak admin events and login events, authentik audit logging, forwarded to a SIEM | Monitoring and logging of authorized user activity under the Safeguards Rule, and PCI DSS logging of access to system components | Logs kept only on the identity host, short retention, or admin events disabled at go-live |
| SIEM collection and alert evidence | SIEM such as Wazuh or Security Onion ingesting identity logs, with detection rules for failed MFA and admin changes | Evidence that logs are reviewed and that anomalous authentication generates a tracked alert | Ingestion is configured but no documented review cadence or ticket trail exists |
| Register of ICT contracts and hosting locations | Organization's contract register maintained by the third-party risk or procurement team, listing the self-hosted identity platform and any support partner | DORA Article 28(3) register of information and Article 30(2) contract content on service locations and data processing | Support partner contracts are missing from the register, or data locations are not stated |
| Exit plan and transition documentation | Written exit strategy covering identity data export, configuration backups and a second identity provider or migration path | DORA Article 28(8) documented and tested exit strategies for ICT services supporting critical or important functions | Plans exist on paper but have not been tested against a real configuration export |
| PCI DSS scoping and network diagram records | Organization's scoping documentation, with identity components marked as in or connected to the cardholder data environment | Scope decisions that determine which identity systems must meet Requirement 8 and logging controls | Identity servers placed outside scope while still authenticating users into the environment |
What financial firms ask before self-hosting SSO: cost, time and effort
What drives the cost of self-hosting SSO for a financial firm?
The cost is driven by who runs the identity provider, how many applications must be connected, and how much resilience the firm needs. Cost components usually include infrastructure in your own cloud account or data center, a production-grade database, the high availability design, application integration work, the MFA and passkey rollout, testing, and ongoing support. Open-source licensing is not the main variable for Keycloak, which is Apache-2.0. For authentik, the open-source edition is MIT-licensed, but features such as privileged access management, mTLS client certificate authentication and enhanced audit logging sit in the enterprise edition. The authentik pricing 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. Ask your team which features your controls depend on before assuming the free edition covers them.
What is one-time and what recurs after an SSO rollout?
One-time costs cover design, initial build, application onboarding, MFA enrollment campaigns and the first security testing of the identity layer. Recurring costs cover hosting, database capacity, backups, monitoring, patching, version upgrades, subscription fees if you buy an enterprise edition, and staff time for new applications and access changes. Keycloak publishes four minor releases a year, so upgrades are a standing operational task rather than a project you finish once. The authentik Operator-style deployments and Compose setups also need the same routine patching. Ask any partner to separate the one-time statement of work from a recurring support retainer, so you can see which costs continue after go-live.
How long does an open-source SSO rollout take for a bank?
The duration depends on scope more than on the software. The main variables are the number of applications that support SAML or OIDC natively, how many applications need custom integration or no SSO support at all, the number of directories to federate, whether high availability is required from day one, and how many approval gates your change process requires. A rollout that starts with a few well-understood applications and one directory is far shorter than a phased migration of core banking, payment and back-office systems. Do not accept a timeline before the written scope lists the applications, directories, environments and sign-off steps. Your partner should state the phases and the exit criteria for each one in the quote.
What does the internal team have to provide for an SSO project?
Your team provides the decisions and access that only the firm can give. That includes named application owners who confirm login flows and test accounts, a directory owner who approves the source of identities and leaver rules, a security owner who defines MFA and passkey policy and the Qualified Individual's approval for any equivalent control under the FTC Safeguards Rule, and infrastructure staff who provide hosts, database capacity, network paths and certificates. Your team also needs a change board that can approve cutovers and a helpdesk that can run enrollment for staff. Without these inputs, timelines slip regardless of the implementation partner's skill, so request a responsibilities matrix as part of the quote.
Can a financial firm run Keycloak or authentik without an outside partner?
Yes, many firms with mature platform teams run Keycloak or authentik in-house, and the software is designed for self-hosting. The questions to answer honestly are whether the team can operate a clustered identity service with a synchronously replicated database, test upgrades before production, handle the operator update approval process, manage schema migrations, and produce evidence for auditors and examiners. Keycloak's Operator documentation recommends manual approval mode for operator updates to avoid unintended upgrades, which shows why a tested change process matters. A partner can cover the parts your team lacks, such as the initial build, hardening, backup and restore testing, documentation and support, while your staff keep ownership of the running system.
How is a fixed-scope quote built for an SSO engagement?
A fixed-scope quote is built from a written scope that lists the deliverables, environments, applications, directories, MFA and passkey requirements, testing, documentation and handover. Most engagements are fixed-scope, so the quote follows the scope agreed in writing before work starts. DeployOpen does not publish a price list, and each quote reflects the specific scope. To compare proposals, ask each provider to state which items are included, which are excluded, which assumptions the price depends on, and what changes would trigger a change request. Ask also whether ongoing support, upgrades and testing are priced separately as a retainer, so the one-time and recurring totals are clear.
Which compliance evidence should an SSO quote include?
The quote should name the evidence the rollout will produce, because examiners and auditors ask for configuration and records, not verbal assurances. Typical items include exported realm or tenant configuration, MFA policy settings, enrollment records, audit log configuration, access review outputs, privileged account controls and change records for upgrades. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing any information system, and PCI DSS v4.0.1 is the active version for cardholder environments. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, which come from independent assessors. Confirm with your assessor which evidence formats they accept before the build starts.
What should a financial firm check before choosing a self-hosted SSO partner?
Check that the partner can show how the identity provider stays available during upgrades and outages, how it tests upgrades before production, and how it documents the configuration. Ask for their approach to database selection, since Keycloak supports PostgreSQL 14 to 18 among other production databases, and to high availability design. Confirm how they handle applications without SAML or OIDC support, how they stage MFA enrollment for staff, and what they hand over at closure. Ask for a sample scope document and an explanation of what is excluded. A credible partner will be specific about these items and will avoid guaranteeing outcomes the scope cannot control.
Questions to ask an implementation partner before a financial SSO project
Start with scope. Ask the partner how many of their past identity projects put applications inside a cardholder data environment (CDE) and how they separated that scope from the rest of the estate. Ask which Keycloak or authentik realms, clients and network paths they would place in the CDE, who can administer them, and how they would show a QSA that the identity provider itself is in scope. Ask whether they will document which PCI DSS v4.0.1 requirements the identity stack supports and which remain with your team, so that the responsibility matrix is agreed before the first configuration change.
Ask how MFA enrollment will reach staff, not only how it is configured. Good answers name a pilot group, a grace period, a help desk script for lost devices, and a fallback path for people who cannot register a passkey or hardware token. For high availability, ask the partner to explain how a Keycloak cluster or the authentik server and worker containers are connected to a database that replicates synchronously, which Keycloak documents as a requirement for its supported designs. Ask which failure they tested, such as losing a database node or an availability zone, and where the results are recorded. For upgrades, ask whether the Keycloak Operator runs in manual approval mode, who approves each update, how schema migration is tested, and whether the partner uses manual migration for large databases.
Ask what the DORA exit plan covers, since Article 28(8) requires documented, tested exit strategies for ICT services supporting critical or important functions. A credible answer covers a data export of realms, users, clients and credentials where the format allows it, a runbook for moving applications to another identity provider, and a test date. Ask what evidence the partner delivers to your compliance team: configuration exports, the upgrade and change log, MFA enrollment reports, backup restore test records, and an inventory of every application that authenticates through the identity provider. Confirm in writing who maintains that evidence after handover and at what interval it is refreshed.
How DeployOpen scopes, builds and supports financial SSO
The sequence below shows how a financial services SSO engagement moves from written scope to a tested, self-hosted identity provider with evidence ready for assessors, and what stays under retainer afterward.
Confirm the company structure and scope in writing
DeployOpen is a Chainscore Labs company. Before any build work starts, both sides agree a written scope covering the applications to integrate, the cardholder data environment boundary if PCI DSS applies, the regulatory drivers (FTC Safeguards Rule, PCI DSS Requirement 8, DORA), the target hosting location and the deliverables. Most engagements are fixed-scope, so the scope document is the reference for acceptance. The step is done when the client's compliance lead and security owner have signed the scope and the deliverables list. Because DeployOpen does not publish a price list, the quote follows from this written scope.
Map applications, directories and MFA requirements
The team inventories each application that needs workforce login, noting whether it supports SAML, OpenID Connect or neither, which directories hold identities (for example, Active Directory or LDAP), and which accounts have privileged access. The MFA policy is mapped to the rules that apply, including the FTC Safeguards Rule requirement for MFA on any information system and the PCI DSS Requirement 8 controls for access into the cardholder data environment. Passkey and phishing-resistant options are decided per user group. The output is a requirements matrix the client signs off, and every application without SAML or OIDC support is flagged with a named compensating approach.
Deploy the identity provider inside your infrastructure
DeployOpen installs Keycloak or authentik in the client's own cloud accounts, data centers or isolated networks, with the database, high availability design and network placement agreed in the scope. Keycloak's supported production databases and its need for a synchronously replicated database in high availability designs are checked against the chosen architecture. Version pinning and the upgrade approach are documented at this stage. The step closes when the staging environment passes a health check, the database is confirmed as production-supported, and the client's operations team can log into the admin console with their own accounts.
Integrate applications and configure MFA and passkeys
Each in-scope application is connected over SAML or OpenID Connect, with directory federation and privileged-role mapping configured. MFA is enabled for all workforce access, with passkeys or WebAuthn registered for administrators and high-risk roles where the platform and client policy support them. Session lifetimes, lockout behavior and login policies are set to the agreed values. Each integration is tested with a standard user, a privileged user and a user with an expired or disabled account. The step closes when every in-scope application has a test record showing successful login, MFA enforcement and denied access for the negative cases.
Harden, back up and document the deployment
DeployOpen applies the hardening baseline agreed in scope, covering transport encryption, administrator account separation, logging to the client's monitoring platform, secrets handling and access to the configuration. Backup and restore are tested on a copy of production data, and the recovery steps are written down. Runbooks cover upgrades, including the Keycloak Operator approach of manual approval mode for operator updates, and incident steps for when the identity provider is unavailable. The output is a hardening record, a restore test report and a runbook set the client owns.
Prepare evidence for assessments without issuing attestations
The team collects configuration exports, MFA enrollment reports, access logs, change records and test results that map to the controls the client is assessed against, such as FTC Safeguards Rule access and monitoring elements, PCI DSS Requirement 8 and DORA ICT risk management and third-party records. DeployOpen organizes this evidence and explains what each item shows. It does not issue audit reports, attestations or certifications. Independent auditors, Qualified Security Assessors or the client's own assessment process make those determinations. The step closes when the client's compliance lead confirms the evidence pack is complete for the assessor they have engaged.
Hand over operations and offer retainers
The client's team receives training on administration, the runbooks and the evidence routine. Where the client wants continued help, DeployOpen offers retainers for upgrades, security patching and continuous testing of the identity layer, scoped separately in writing. Upgrade planning follows the project's release cadence, and Keycloak's documented practice that breaking changes in minor releases are opt-in is reflected in the upgrade test plan. The step closes with a signed handover record listing the owners of each component and the retainer scope, if one was chosen.
