Open source customer identity for PSD2 strong customer authentication starts with two independent elements
If you are an EU bank, payment institution or fintech, the identity layer must produce two independent elements from knowledge, possession and inherence before a customer logs in or initiates a payment. A self-hosted platform such as Keycloak or ZITADEL can produce those elements and enforce them consistently across login and step-up flows, but the payment system still owns transaction linking and dynamic binding, meaning the proof that a specific amount and payee were approved. Under the EBA's Opinion on the elements of strong customer authentication (EBA-Op-2019-06), SCA is authentication based on two or more independent elements, so that a breach of one does not compromise the others. The RTS on strong customer authentication, Commission Delegated Regulation (EU) 2018/389, was published in the Official Journal on 13 March 2018 and applied from 14 September 2019.
Map each login and payment path to its factors before you configure anything. A password or PIN is knowledge. A passkey stored in a device secure element, or a one-time password from a bound authenticator app, is possession, and a biometric unlock on that device may count as inherence only if the device validates it locally. The EBA states that apps, browsers or key exchanges count as possession only when a device-binding process ties them uniquely to the device. Confirm with your supervisor and your qualified assessor how each combination of factors maps to the elements, and document the binding enrollment, since that record is what an examiner will ask for.
DeployOpen prepares the systems, configuration, test evidence and documentation for your SCA review, but it does not issue audit reports, attestations or certifications. Those come from your supervisor, auditors and certification bodies. Agree in writing which controls the implementation covers and which remain with your payment processing, fraud and transaction teams, and have your compliance lead confirm how the Keycloak or ZITADEL configuration will be evidenced under DORA and your national rules.
Mapping SCA elements to identity platform configuration
This table maps each PSD2 strong customer authentication element and supporting control to what the identity platform must do and how Keycloak or ZITADEL can be configured for it. Read each row as a question to put to your team and your assessor: what is configured, what evidence is produced, and where the design usually breaks.
| Requirement | What the function must do | How to configure Keycloak or ZITADEL |
|---|---|---|
| Knowledge element (EBA-Op-2019-06) | Verify something only the user knows, such as a password or PIN, without exposing it to the relying party or logs | Keycloak: password policy and credential validation in a browser flow. ZITADEL: password login with lockout settings. Confirm hashing and lockout behavior in your version |
| Possession element (EBA-Op-2019-06) | Prove control of a device through an OTP generated by software or hardware, or a device-bound credential | Keycloak: OTP enrollment as a required action in the browser flow. ZITADEL: TOTP or passkey as second factor. Confirm which OTP and device types your bank approves |
| Inherence element (EBA-Op-2019-06) | Verify something the user is, typically via a biometric unlock on a device that then releases a possession-bound credential | Passkeys with user verification set to required, using FIDO2 and WebAuthn. ZITADEL documents passkey login; Keycloak supports WebAuthn credentials. Confirm that biometric results stay on the device |
| Device binding | Tie a mobile app, browser or key exchange uniquely to one device so the possession claim cannot be copied | Register each app instance as a device credential at enrollment and bind it to the user. Revoke on device change. Confirm the binding process with your PSD2 assessor, since EBA treats unbound apps as not possession |
| Independence of elements | Ensure that compromise of one element does not compromise the others, for example separate channels for password and OTP | Keep password and second factor in separate flow steps with separate secrets, and do not let a recovery flow bypass both. Document the flow diagram as evidence |
| Step-up for payment flows | Apply a fresh SCA with dynamic linking to amount and payee when a payment is initiated | Use a conditional step-up sub-flow or a dedicated client scope that requires a new authentication with a reference to the transaction. Confirm how the payment system receives the authentication result |
| Evidence logging | Record authentication events, factor used, device and outcome in a form that can be examined later; also supports FTC Safeguards MFA and PCI DSS logging where they apply | Enable event logging and export authentication events to a SIEM such as Wazuh. Retain factor type and result per event. Confirm retention periods with your compliance lead |
Which open source identity platform fits a PSD2 program
PSD2 strong customer authentication is a property of the flows you build, so the platform choice comes down to which authentication methods it supports natively, how it handles device binding and how it runs in your environment. The four options below differ mainly in licensing, data model and how much flow customization you will own.
Keycloak for flow-level control
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with authentication flows that can be customized to chain password, OTP and passkey steps. Its production databases include PostgreSQL, Oracle Database and Microsoft SQL Server. For a PSD2 program, check how your device-binding step is implemented, because the platform does not decide whether an app counts as possession. High availability designs require a synchronously replicated database, so include that in your infrastructure review.
ZITADEL for passkeys and tenancy
ZITADEL is licensed under AGPL-3.0 and lists passkeys based on FIDO2 and WebAuthn, OpenID Connect, SAML 2.0 and SCIM v2 among its features. It organizes tenants as instances with full data isolation, which can suit banks running separate brands or entities. Self-hosted deployments use PostgreSQL 14 through 18. Under AGPL-3.0, if you modify the core and make it available to users over a network, you must offer those modifications under the same license, so confirm this with legal counsel before customizing the core.
Ory Kratos and Hydra as a split
Ory Kratos handles identity and user management, while Ory Hydra acts as the OAuth 2.0 and OpenID Connect server, and both are licensed under Apache-2.0. This split suits teams that want to build the login experience and the consent screens themselves and keep token issuance separate. The cost is integration work: you must connect the two components and build the login and step-up logic yourself. Confirm the passkey and device-binding features you need against the current Ory documentation before committing.
authentik as a comparison
authentik is licensed under MIT except the authentik/enterprise directory, which carries a separate enterprise license, so confirm which features your program would need from that directory. It is a useful comparison point for teams that want a single self-hosted server with a visual flow editor. Check whether its supported passkey, OTP and device-binding options meet your PSD2 design, and document which parts sit under the enterprise license before selection.
What stays in the payment system and out of identity
The identity platform produces the authentication event: it verifies the customer's elements, records the method used and issues tokens that describe that login. The payment system has to do something different. It must bind the authenticated customer to the specific transaction, including the exact amount and payee, and it must enforce dynamic linking so that an approval cannot be reused for a different amount or beneficiary. Exemption decisions, such as low-value or trusted beneficiary handling, also sit with the payment stack and the acquirer or issuer, not with the login server. Identity can support this by passing a clear record of when and how the customer authenticated, but it should not be the place where transaction limits or fraud scoring are decided.
Keep the boundary explicit in your architecture. In a Keycloak or ZITADEL design, the claims and events leaving the identity layer should be limited to facts such as the authentication method, the time of authentication and the session identifier, typically carried in tokens or authentication context values your payment service validates. The payment service should check that the token is fresh enough for the transaction and that the transaction data it approved matches what was signed or submitted. Decisions about amount thresholds, velocity rules, device risk scores and whether a transaction is exempt belong to your payment fraud and risk engine. Passing risk signals into identity for step-up decisions is common, but document which system makes the final call and who owns it.
Confirm the split with your national competent authority and your legal counsel before you design the handoff, because the allocation of responsibility for dynamic linking and exemptions depends on your license type, your role in the payment chain and national implementation. Ask your payment partners, including the acquirer, issuer or processor, how they expect authentication results to be communicated and what evidence they need to keep. Also confirm with your assessors which systems fall inside your payment card scope, since the identity platform may or may not be part of the environment that stores, processes or transmits cardholder data. Make those answers part of the written design so that auditors can trace each decision to a system owner.
Evidence an assessor will ask for and which component produces it
This table maps the evidence a PSD2 assessor or internal auditor typically asks for against the component that produces it, with Keycloak events, ZITADEL audit data and SIEM ingestion as the main sources. Read it as a starting inventory: each source needs to be enabled, configured and forwarded deliberately, and the retention period must be confirmed with the institution's compliance function.
| Evidence item | Source component | Retention to confirm with the institution |
|---|---|---|
| SCA policy and element inventory | Design document and configuration export from Keycloak realms or ZITADEL instances, kept under version control | Keep every superseded version for the period the institution's policy and supervisor expect |
| Authentication event logs with timestamps and factor used | Keycloak events (login and authentication events) or ZITADEL audit records, forwarded to the SIEM | Confirm the log retention period with the compliance team and check whether the SIEM tier can hold it |
| Device binding records | Keycloak credential records for registered devices or ZITADEL passkey and device registrations, with registration timestamps | Confirm whether bindings are kept after the user leaves or the device is removed |
| OTP enrollment and revocation records | Keycloak required-action and credential events, or ZITADEL user events for OTP setup and removal | Confirm retention alongside authentication logs and any customer complaint records |
| Configuration baselines and change history | Realm and client configuration exports, Keycloak Operator custom resources in Git, and ZITADEL management API change records | Confirm how long change approvals and pull request history must be kept |
| Upgrade and patch records | Release notes, change tickets and Keycloak or ZITADEL version records, plus operator update approval logs | Confirm with the institution's change management and DORA ICT risk documentation requirements |
| Access control to the identity administration console | Admin event logs in Keycloak, ZITADEL administrator audit records, and privileged access records from the PAM layer | Confirm retention and who reviews the administrator access log, and how often |
What the identity platform alone does not satisfy
A compliant SCA login flow is one control among many. The payment core, fraud engine, card data scope, outsourcing rules and the institution's own risk decisions still carry their own evidence, and an identity platform does not produce it. Read each card as a boundary to agree with your payment, risk and compliance teams before the identity design is locked.
Transaction linking in the payment core
SCA for a payment must be dynamically linked to the amount and payee shown to the customer, so a code or approval cannot be reused for a different transaction. Keycloak or ZITADEL can authenticate the customer, but the payment core must carry the transaction data into the authentication step and check it at authorization. Ask the payment platform team who owns that binding and where the transaction data is signed or stored.
Fraud and risk engine
Transaction risk analysis and the exemptions it enables depend on signals the identity platform does not decide: device history, payee patterns, amounts and velocity. The identity provider can pass a session or device reference, but the risk engine must score the transaction and decide whether SCA is required. Confirm which system records the exemption decision and how it is audited.
PCI DSS scope and assessment evidence
If the login flow touches cardholder data or sensitive authentication data, or could affect the cardholder data environment, the identity servers and their hosts may fall in PCI DSS scope. The assessment is a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the payment brands decide which applies. Confirm scope boundaries early, and remember that DeployOpen prepares evidence but does not issue these documents.
DORA register and exit strategy
For EU financial entities, DORA requires a register of information on all contractual arrangements for ICT services, and documented, tested exit strategies for services that support critical or important functions. A self-hosted Keycloak or ZITADEL deployment still counts as an ICT arrangement when a provider supplies support, upgrades or hosting. Keep the register entry, the exit plan and the tested migration path of user data current.
Third-party contract terms
DORA Article 30 expects each ICT services contract to state where services are provided and data processed, to require advance notice of changes, and to cover data return on insolvency or termination. Open source licence and support choices shape these terms: AGPL or Apache licensing governs the code, but a paid support or hosting contract is what carries the location, notice and exit commitments. Ask any partner or vendor for these clauses in writing before go-live.
Institution's own risk assessment and exemptions
The institution must document its own risk assessment for SCA, the exemptions it relies on, and the approval of each exemption, and it must be able to show these to its supervisor. Passkeys, OTP and device-bound apps are choices the risk team should record with reasons, including fallback paths and their risk. Confirm that the identity design, the fraud rules and the audit trail are tied to one reviewed risk register.
How much work and cost does a PSD2 SCA implementation involve?
What drives the cost of a PSD2 SCA implementation?
The biggest cost drivers are the number of channels that need SCA, the identity stores you must connect, and how much of the authentication scope you deliver at launch. Each web, mobile and partner channel adds login, step-up and session work. Existing directories, such as Active Directory or an older customer database, add federation and data-mapping work. Passkey and OTP scope adds device-binding design and testing. High availability design and the migration of existing customers also add infrastructure and effort. Ask any quote to break these items out separately so you can see which ones you can defer.
How long does a PSD2 SCA project take?
No duration should be promised before the scope is written. The schedule depends on how many channels move to SCA, whether device binding for apps is in scope, how many customers must migrate, and how fast your payment core and change-approval processes respond. Ask the partner to state the timeline, phases, dependencies and acceptance criteria in the written scope, and to name which milestones depend on your team's reviews. Treat any timeline given before the scope is agreed as an estimate, not a commitment.
What does the bank or fintech need to provide during implementation?
Most delays come from missing inputs rather than from the software. You will need a named product owner who can decide on login and step-up journeys, engineers who know the payment core and its interfaces, and access to the channels, test accounts and device types used by customers. Security and fraud teams must confirm the risk rules that trigger SCA and exemptions. Compliance should identify the regulator contacts and internal approvers who will review the design and evidence. Agree these roles and their time commitments in the scope before work starts.
Can our internal team implement PSD2 SCA without a partner?
A team with strong identity engineering skills can build SCA with Keycloak or ZITADEL, but the work usually extends beyond the identity platform itself. It includes operating a production database, a clustered deployment with synchronously replicated storage, upgrade and patch cycles, monitoring, and testing of every channel. It also includes evidence for PSD2, PCI DSS where card data is involved, DORA where ICT third-party and exit rules apply, and any Swift or FTC obligations. Assess honestly whether these skills are already on staff and whether they can be staffed through the go-live and the first upgrades.
Can an implementation partner prepare compliance evidence for PSD2 SCA?
A partner can prepare the systems, configuration records, test results and documentation that your assessors will review, but it cannot issue an audit report, attestation or certification. Under PCI DSS, for example, the assessment is documented as a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. Your payment brands and internal audit determine what is needed. Ask the partner which evidence items it will produce, how they map to your assessor's requests, and which decisions remain with your compliance team.
What recurring costs follow the launch of PSD2 SCA?
After go-live, recurring costs include hosting and database capacity, backups, monitoring, security patching, and the upgrade cycle. Keycloak plans four minor releases a year, so budgeting for regular upgrade testing is prudent. Recurring evidence work, such as annual assessments, access reviews and change records, also needs staff time. Support can be handled in-house or through a retainer agreed in writing. Ask any partner to separate one-time implementation fees from ongoing support, upgrade and testing fees, and to state what each one covers.
How should we handle migrating existing customers to new SCA methods?
Migration effort depends on how many customers already have credentials, whether their passwords can be moved or must be reset, and how many devices need binding. Keeping password or OTP fallback during transition adds testing and support load but reduces lockout risk. Plan communications, staged rollouts and a rollback path. Ask the partner how it will test migration with representative customer data, how it will measure adoption and how it will handle customers who cannot complete enrollment.
Does the high availability design change the cost of PSD2 SCA?
Yes. Keycloak documents a single cluster optionally spread across availability zones, multi-cluster deployments without external Infinispan, and the deprecated multi-cluster v1 design. Both supported designs require a synchronously replicated database. Each option changes the number of nodes, the database licensing or service tier, the network links and the test effort for failover. Ask the partner which design it recommends for your recovery targets, what failover tests it will run, and what the ongoing infrastructure cost will be in your own environment.
How an SCA rollout moves from design to evidence
The sequence turns a PSD2 strong customer authentication requirement into configured factors, tested negative paths, a controlled cutover and an evidence pack that an assessor or internal audit can follow. Each phase closes with a named output so that scope creep and gaps surface early.
Inventory payment journeys and authentication elements
The bank, payment institution or fintech lists every customer-facing journey that touches a payment or sensitive account action, including login, enrollment, payee creation and card or contact changes. For each journey, the team records which knowledge, possession and inherence elements are used today and which exemptions the institution may rely on. Compliance, fraud and product owners sign the inventory. It is done when every journey has an owner and a documented element list that can be traced to a requirement.
Select the platform and design the architecture
The team compares Keycloak, ZITADEL and other candidates against the factor types, device-binding approach, high availability needs and data residency the inventory produced. Deployment target, database and network zones are fixed in a written architecture decision, including which component holds the authentication decision and how it reaches the payment system. Keycloak documents supported production databases and high availability designs, and ZITADEL documents PostgreSQL and Kubernetes deployment, so the team confirms both against the chosen environment. Done when the architecture review is approved and the vendor support position is recorded.
Configure factors and device binding
Engineers configure password or knowledge factors, OTP, passkeys and any device-bound app flow, and define which combinations satisfy two independent elements. For app-based possession, the device-binding process must tie the app or key to a specific device, and the team tests re-enrollment and device replacement. Settings are stored as code or exported configuration so changes are reviewable. Done when each journey maps to a documented factor combination and binding test results are attached to the configuration record.
Integrate with payment channels
The identity platform is connected to online banking, mobile apps, card and payment initiation channels through standard OpenID Connect or SAML flows, and step-up is triggered for sensitive actions. The team confirms which payment system components receive an authenticated session or assertion and which must independently validate the transaction. Data flows are logged and the fields passed to the payment system are reviewed for minimization. Done when end-to-end flows run in a test environment and the interface specification matches what the payment system actually consumes.
Test positive and negative cases
Testers run the expected paths and then the failure paths: wrong factors, replayed OTPs, expired sessions, a second device claiming a bound app, lost passkeys, bypass attempts on step-up and direct calls that skip the authentication step. Results are logged against each journey in the inventory. Security testing is run by an independent team where possible, and findings are tracked to closure with retest evidence. Done when every negative case has a recorded outcome and no open high-severity finding blocks cutover.
Cut over with a tested fallback
The rollout moves journeys in controlled waves, starting with a limited population or a single channel. The team agrees rollback criteria in writing before the first wave, rehearses the rollback and confirms that sessions and enrolled factors can be restored or re-established. Monitoring covers failed logins, step-up rates and support contacts. Done when each wave passes its exit criteria and the fallback has been exercised in a non-production environment.
Assemble the evidence pack and hand over
The team compiles the element inventory, architecture decision, configuration exports, test records, change approvals, monitoring baselines and the rollback rehearsal into one pack indexed to the requirements it supports. Operators are trained on runbooks for enrollment reset, device replacement and incident handling. DeployOpen prepares this evidence, but the bank or payment institution, its auditors and its supervisor decide what it proves. Done when the client's compliance owner accepts the pack and operations confirms ownership of each runbook.
How DORA and PCI DSS shape the same identity design
DORA has applied since 17 January 2025 to credit institutions and payment institutions, and it reaches the identity platform as an ICT service. Under Article 28(3), the institution must keep a register of information covering every contractual arrangement for ICT services, so a self-hosted Keycloak or ZITADEL deployment, its database, its hosting provider and any implementation partner each need an entry. Article 28(8) requires documented and tested exit strategies for ICT services that support critical or important functions, which for customer login is very likely the case. Article 30(2) asks that every ICT services contract state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Confirm with your legal and third-party risk teams how these map to your contracts before the identity build starts, because the answers shape hosting regions, backup locations and the migration path out of the platform.
PCI DSS v4.0.1, published 11 June 2024, applies wherever cardholder data or sensitive authentication data is stored, processed, transmitted or could affect that environment. Card issuers, acquirers, merchants and processors fall in scope, and the login flows for card management or payment authorization often sit close to it. The PCI SSC does not enforce compliance itself. The payment brands decide who must validate, and the evidence takes the form of a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire, each backed by an Attestation of Compliance. Ask your acquirer or payment brand which validation route applies to your entity, then confirm with your assessor which identity components sit inside the cardholder data environment and which sit outside it.
How DeployOpen scopes and delivers a PSD2 SCA identity build
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For PSD2 strong customer authentication, we start from the written scope, agree which authentication elements and payment flows are in or out, and deliver the identity layer with its evidence so the bank or fintech can take it into its own assessments.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which login, step-up and payment confirmation flows run in the identity platform and which remain in the payment system.
- We confirm each SCA factor in use and how device binding will be proven for apps, browsers and key exchanges.
- We agree with your compliance team which evidence the identity build must produce for assessors.
How we build
- We install and configure the chosen platform, such as Keycloak or ZITADEL, in your cloud accounts, data centers or air-gapped network.
- We set up passkey, OTP and device-bound app flows, with password fallback where the agreed scope requires it.
- We integrate the platform with core banking, payment gateways, customer directories and logging systems through documented interfaces.
- We test login, step-up and recovery paths, including negative tests for factor bypass and session handling.
How we hand over
- We deliver architecture, configuration and runbook documentation covering factors, flows, realms or tenants and high availability.
- We provide the test results and control mapping that your team and independent auditors can review.
- We train your operations staff on upgrades, backups, database migration and incident procedures.
- We confirm handover acceptance against the written scope before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial scope.
- We plan upgrades around the vendor's release cadence and review breaking changes before they reach production.
- We can run periodic security testing of login flows, APIs and account recovery paths on request.
- We do not issue audit reports or attestations; independent assessors and certification bodies provide those, and we prepare the evidence.
