Open source customer identity for financial services

Examiners expect a dated export showing which factors are enabled for customers and staff, which flows require them, and how exceptions were approved. The FTC Safeguards Rule at 16 CFR 314.4(c) requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, so the written approval is evidence in its own right. On Keycloak, the realm and authentication flow configuration can be exported as JSON and stored under change control. On ZITADEL, login policy settings and passkey and MFA requirements can be exported through its APIs or Terraform configuration. Your team should confirm the exact export method for the version you run. The integration partner prepares the export procedure, and independent assessors decide whether the evidence is sufficient.

Assessors look for logs that show who signed in, with which factor, from where, and what administrators changed. The FTC Safeguards Rule requires monitoring and logging of authorized user activity, and 45 CFR 164.312 audit controls show the same principle for health data. Keycloak emits login, failed login, and admin events that can be forwarded to a SIEM, and it exposes metrics for monitoring. ZITADEL records audit events for administrative actions. Forward these streams to a log platform such as Wazuh or Security Onion, define retention with your compliance lead, and test that a sample login can be traced end to end. Confirm event coverage, field names and retention for your exact versions before you commit to a log design.

Access reviews show that only approved people hold administrator rights to the identity platform and that the rights are checked on a set cycle. Produce a list of every realm, organization, or instance administrator, the role each holds, the approver, and the date of the last review. Keycloak administrative roles and ZITADEL instance and organization roles can both be exported for this purpose. Where identity governance tooling such as midPoint is in place, it can generate certification campaigns from the same data. Your team should set the review frequency with its own policy owner. Auditors test the reviews themselves, so the signed records matter as much as the list.

Assessors check that customer information is encrypted in transit and at rest, as the FTC Safeguards Rule requires, and that the settings are documented. For transit, collect the TLS configuration on the public endpoints, the certificate sources, and the internal connections between the identity server, its database, and the proxy. For rest, collect the database encryption method, key storage location, and key rotation records. Keycloak and ZITADEL both need a supported production database, and the database encryption setting belongs in the evidence pack. Where secrets and keys are managed with OpenBao or Infisical, their configuration and access logs are supporting evidence. Confirm each setting against your cloud provider or data center controls, because the platform does not encrypt storage by itself.

Change records should show what was upgraded, when, who approved it, what was tested, and how it can be rolled back. For Keycloak, the Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades, so the approval itself becomes a change record. Keep release notes, the version tested in staging, database migration output, and the rollback plan for each change. Keycloak migrates its schema at startup by default, but administrators can apply the SQL manually, which the upgrading guide suggests for large deployments. Ask your partner to document which approach is used and why. Evidence of routine change control is often what assessors test first when they review operational controls.

DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies and transition plans for services that support critical or important functions. For self-hosted customer login, the register entry should name the open-source platform, the hosting location, the internal and external service providers, and the data processed. The exit plan should describe how identities, credentials, and client configurations would move to another platform, and how the plan was tested. Article 30(2) also requires contracts to state where services and data are located and to cover data return. Your legal and risk teams own the register and exit plan. An implementation partner can supply the technical inputs, such as data export procedures and architecture diagrams.

A PCI DSS assessment needs evidence showing how the login platform protects cardholder data environments and sensitive authentication data where it applies. PCI DSS applies to entities that store, process or transmit cardholder data, or that could affect the security of that environment. Assessors typically look at access control, MFA for administrative and remote access, logging, encryption, and change management, and they record the outcome in a Report on Compliance or a Self-Assessment Questionnaire. Prepare network diagrams, data flow diagrams, the authentication configuration export, and log samples. PCI DSS v4.0.1 is the only active version, so use its current requirement numbers when mapping evidence. Independent Qualified Security Assessors issue the Report on Compliance, and DeployOpen prepares the systems and evidence but does not issue reports or attestations.

Independent assessors issue the final report, and the platform team does not. Depending on the framework, that may be a Qualified Security Assessor for PCI DSS, an internal or external auditor for SOX or DORA-related reviews, or a regulator-accepted assessor. DeployOpen prepares systems, controls and evidence for these assessments, but it does not issue audit reports, attestations or certifications. The Swift Customer Security Controls Framework also requires independent assessment and annual attestation in the KYC-SA application if your institution is a Swift user. Confirm with your compliance lead which assessor, which framework and which evidence period apply before collecting anything, so the evidence pack matches what the assessor will test.

Ask for a written mapping that lists each login path, administrative path and customer path, then states which rule applies to each one. The FTC Safeguards Rule at 16 CFR 314.4(c) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. PCI DSS scope is set by whether a system stores, processes or transmits cardholder data or could affect the cardholder data environment, so the identity store may fall in or out of scope depending on the design. A good partner will show how the Keycloak or ZITADEL realms, clients and step-up rules map to each requirement, and will name who signs off on the scope decision. Confirm whether your payment brands or acquirer have set a validation level, since they decide who must validate.

The identity platform should hold only what it needs to authenticate and authorize a user, such as credentials, passkey public keys, profile attributes and role claims. Ask the partner to show the data inventory for the realm or instance, and to confirm that primary account numbers, card security codes and sensitive authentication data never reach user attributes, custom fields, event logs or token claims. Check how event logging and admin exports are configured, because logs are a common place where sensitive values leak. Ask who reviews the token mapper configuration and how changes to it are tested before release. The answer should name the systems that do hold card data and how identity tokens reference them without carrying the data.

Ask for the load test plan, the target login rate, the peak profile used for the test and the pass criteria written before the test runs. Keycloak documents three high availability architectures, and both supported multi-site designs require a synchronously replicated database, so ask which one is proposed and how the database replication is tested. Failover tests should cover a node loss, a database switchover and a site loss, with the expected behavior for in-flight sessions and token refresh stated in advance. Confirm which metrics are exposed for monitoring, since Keycloak documents metrics configuration, and who watches them after launch. Peak targets should come from your own transaction calendar, not from a vendor default.

Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, but a bank still needs a tested upgrade path. Ask the partner how they pin versions, stage upgrades through non-production environments that match production, and decide between automatic and manual database schema migration. Keycloak migrates the schema at startup by default, while its upgrading guide suggests manual migration for large deployments, so ask which mode applies and who runs the SQL. For Kubernetes deployments, ask whether the Keycloak Operator is set to manual approval mode, which the Operator documentation strongly recommends to avoid unintended upgrades. Ask for the rollback procedure and how long a rollback has been rehearsed.

DORA applies to many financial entities, and Article 30(2) requires every ICT services contract to state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Article 28(8) requires documented, tested exit strategies for ICT services that support critical or important functions. Ask the partner to draft the exit plan and the data return clauses for the implementation contract, and to show how the exit would be tested against your own identity data. Confirm that the register of information under Article 28(3) includes the self-hosted platform, the partner and any subcontractors. Your legal and third-party risk teams should confirm the applicability of DORA to your entity.

Ask for a written list of deliverables, including the architecture document, configuration exports, the MFA and step-up rule mapping, test reports for login load and failover, the upgrade and rollback runbooks, and the access control records for administrative accounts. Ask how the evidence is versioned and where it is stored, since it should live in your environment. Confirm that DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies. Ask which of the artifacts your assessor expects, and whether the partner will walk the assessor through them.

The answer depends on the skills you already have and the support model you choose. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. Ask the partner to separate one-time costs, such as design, integration and migration, from recurring costs, such as your infrastructure, database licenses, monitoring, on-call staffing and upgrade testing. Your own team will still own the admin roles, the step-up policies and the change approvals. Ask for a quote that lists who is paid for each component, and request a handover plan with named skills your staff must hold.

Ask for the test cases that cover credential stuffing, phishing of one-time codes, session hijacking and passkey enrollment abuse, plus the step-up triggers for payees, limits and device changes. Ask whether the partner runs these tests as part of security testing for applications, APIs and authentication flows, and how findings are tracked to closure. Confirm which events are logged, how long they are retained, and how they reach your monitoring and incident response tools. Ask for the fallback and recovery flow when a customer loses a passkey, and who approves it. Test results should be reviewed by your own security team before the production launch.