Why open source MFA for financial services starts with the FTC Safeguards Rule
If you are a non-bank financial institution or fintech under FTC jurisdiction, the FTC Safeguards Rule requires multi-factor authentication for any individual accessing any information system, and that scope is the starting point for every design decision on this page. Under 16 CFR 314.4(c), the rule does not stop at VPNs or administrator consoles. It reaches email, core banking and lending systems, reporting tools and any other path a staff member, contractor or vendor uses to touch customer information. Banks answer to prudential examiners rather than the FTC, but examiners increasingly ask the same question: can you show that every access path carries a second factor, and who approved any exception? The rule also provides a written-exception path. Under 16 CFR 314.4(c)(5), the Qualified Individual may approve an equivalent control in writing, so every system without MFA needs a signed record that explains the compensating control and why it is equivalent. Treat that memo as a design input, not paperwork. Build an inventory of access paths first, then sort them into those that can take MFA now and those that need a documented exception. Confirm the exact wording of the exception with your counsel or compliance lead before relying on it.
On platforms, the split is practical. privacyIDEA fits the legacy paths that financial firms struggle to cover: RADIUS for VPNs, the PAM module for Linux and SSH, the Windows credential provider and the REST API for internal web applications. It can read users from existing LDAP or Active Directory stores and supports hardware tokens, FIDO2 keys and smartcards alongside OTP, so one second-factor service can cover several paths. For the web and single sign-on layer, Keycloak or ZITADEL is usually the better fit, since both handle OpenID Connect and SAML and can enforce MFA at the identity provider rather than per application. Confirm current feature support against each project's documentation before committing, because token and protocol coverage differs by version.
Which financial rules set MFA scope and what each means for the build
This table lists the financial rules that decide where MFA is required, the exact obligation each one places on the build, and the evidence an examiner or assessor will expect. Read each row as a question to confirm with counsel, your examiners and your qualified assessor, since scope depends on your license type, payment role and contracts. The main takeaway is that the FTC Safeguards Rule sets the broadest MFA baseline, while PCI DSS, DORA, Swift and SOX add scope and evidence duties for specific systems.
| Requirement | Source | What it means for the MFA build |
|---|---|---|
| MFA for any individual accessing any information system | FTC Safeguards Rule, 16 CFR 314.4(c) | Cover every user path into systems holding customer information, including VPN, email, admin consoles and core systems, not only remote access. Confirm with counsel whether your institution is a covered non-bank entity. |
| Written equivalent-control exception | FTC Safeguards Rule, 16 CFR 314.4(c)(5) | An alternative to MFA must be approved in writing by the Qualified Individual. Keep the signed approval, the compensating control design and a review date with the MFA inventory. |
| Monitoring and logging of authorized user activity | FTC Safeguards Rule, 16 CFR 314.4 (monitoring element) | MFA events such as enrollments, failures, bypasses and resets should flow to your log store. Confirm retention and review ownership with your examiner before go-live. |
| Encryption of customer information in transit and at rest | FTC Safeguards Rule, 16 CFR 314.4 (encryption element) | Token enrollment, RADIUS, LDAP and SAML traffic between MFA components and clients must be encrypted. Store token seeds and MFA databases encrypted and document key custody. |
| Cardholder data environment access and MFA expectations | PCI DSS v4.0.1 (PCI SSC) | If you store, process or transmit cardholder data, or could affect that environment, MFA scope extends to CDE access paths. Confirm with your acquirer or payment brand which entities must validate and how. |
| ICT contracts and exit planning for MFA services | DORA, Regulation (EU) 2022/2554, Articles 28 and 30 | Record self-hosted MFA and any partner support in the ICT register, document exit and transition plans for critical functions, and confirm data location and return terms in contracts. Confirm applicability with your EU supervisor. |
| Access control to programs and data | SEC Release 33-8810 (SOX Section 404 IT general controls) | Authentication and access approvals for systems that affect financial reporting need documented design and periodic evidence. Ask your auditor which systems fall in scope and which tests they will run. |
| Customer Security Programme controls for Swift users | Swift Customer Security Controls Framework v2026 | Swift users must have the controls independently assessed and attest annually in the KYC-SA application. Confirm which MFA-related controls apply to your Swift connected systems and how your assessor will test them. |
Which systems and accounts must sit behind MFA first
Start with the accounts that reach your network and money, then widen the scope to everything else. 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. For a financial institution, the first wave usually covers remote access through VPN and any other gateway into the internal network, email and collaboration tools, and administrator and privileged accounts on directories, hypervisors, firewalls and security tools. Core banking and payments administration consoles belong in the same wave, because a compromised administrator there can change balances, limits or beneficiaries. Customer-facing staff portals, such as loan origination or servicing tools, follow once the high-impact paths are closed.
The rule language is broad, so the inventory must go beyond human employees. Service accounts, API users, scheduled jobs with interactive logins, contractor and vendor accounts, and shared or break-glass accounts all access information systems. Each needs a documented answer: enforce MFA, route it through a privileged access tool that enforces MFA, or record an exception approved in writing by the Qualified Individual with a compensating control. Build the list from your asset and identity inventory, not from memory. Export accounts from the directory, the VPN and the core platform, match them to owners, and count each system where a login is possible. Gaps usually sit in accounts nobody owns.
Before you finalize scope, confirm three points in writing with the Qualified Individual: which exclusions are approved, which compensating controls replace them, and when each exclusion is reviewed. Ask your implementation partner to show how a self-hosted MFA server, such as privacyIDEA with its privacyidea user store connectors, will cover each system in the list, and how you will prove coverage with login logs from each integration point.
Which open source MFA platforms fit financial services and why
Financial institutions need a second factor on VPNs, administrator access and core systems, plus evidence that identities are issued and removed under control. The platforms below cover different parts of that job, so the choice depends on which systems come first and which directory already holds the users.
privacyIDEA for second factors
privacyIDEA is the most direct fit for adding MFA to existing estates. It sends second-factor checks through RADIUS for VPNs, through a PAM module for Linux and a credential provider for Windows, and through Keycloak or SAML plugins for web logins. It reads users from LDAP or Active Directory and supports hardware tokens, FIDO2 keys and PIV smartcards. Check that your VPN, Windows and Linux builds match the supported integrations, and have counsel review AGPLv3 obligations before modifying the code.
Keycloak for SSO and federation
Keycloak gives the bank one place to enforce MFA for web applications through OpenID Connect and SAML 2.0, with WebAuthn support and federation to LDAP and Active Directory. Its Apache-2.0 license is permissive, which simplifies legal review for most teams. The design work sits in clustering and database choice: production deployments need a supported database and a synchronously replicated setup for high availability. Confirm that each core application you plan to protect accepts the protocol Keycloak will issue.
ZITADEL for passkeys and multi-tenancy
ZITADEL lists MFA, passkeys through FIDO2 and WebAuthn, OpenID Connect certification, SAML 2.0 and SCIM in its feature set. It suits institutions that want passkeys as the default for staff and a platform that supports separate tenants, such as business units or subsidiaries. Its AGPL-3.0 license requires review when the software is modified or offered over a network, so involve counsel early. Confirm the directory sync and SCIM provisioning your HR system needs before committing.
FreeIPA for Linux directory and OTP
FreeIPA combines a directory, Kerberos, certificate management and OTP for Linux estates, so it can hold the accounts that SSH and sudo rely on. It works well where the bank runs many Linux servers and wants central policy rather than per-host setup. Its scope is narrower than a full identity platform for web or VPN access, so pair it with a second-factor server where those are needed. Confirm how it integrates with your Active Directory trust and your existing privileged access tooling.
midPoint for joiner, mover and leaver evidence
midPoint is an identity governance platform that automates provisioning, role changes and removals, and produces the review records that examiners ask for. Its EUPL 1.2 license permits use with a copyleft obligation on modifications, which counsel should check before customization. Its evidence supports the access control questions raised by the FTC Safeguards Rule and by SOX IT general controls. Confirm connectors for your HR, core banking and Active Directory sources, and the support window for the release you adopt.
How deployment constraints change the MFA design for banks and fintechs
In an on-premises data center, the MFA server usually sits alongside the VPN concentrators, directory services and core banking access paths it protects. This keeps authentication data inside facilities the institution already controls, which simplifies data residency questions. The design work is mostly about placing redundant nodes across separate racks or sites and making sure the MFA database is not a single point of failure.
- Server placement: Run privacyIDEA or Keycloak nodes in the same security zone as the directories they read, with the VPN and admin paths reaching them over controlled firewall rules.
- Database: Put the token and policy database on a replicated platform with a tested failover, and confirm which database engines your chosen product supports before you commit.
- High availability: Plan at least two independent MFA nodes so a single host failure does not stop logins for branch staff or administrators.
- Change control: Schedule upgrades through the existing change process and test them in a staging environment that mirrors production.
- Contract scope: Record in the register of information which facilities hold authentication data and whether the provider of any support service can access them.
Before approving the design, confirm with the internal audit team which facilities are in scope for DORA Article 28(3) reporting and whether the support provider's staff can reach the MFA database.
Hybrid designs keep some regulated applications on premises while others run in a public cloud account. The MFA server must serve both sides without forcing every login through a path that depends on one cloud region. Many institutions therefore run one MFA cluster in a location they control and treat cloud-hosted applications as relying parties that call it over a controlled connection.
- Server location: Keep the MFA server and its database in a jurisdiction and account you control, and document the regions where any backup copies are stored.
- Connectivity: Use private links or VPN tunnels between cloud workloads and the MFA service, and test what happens when that link drops.
- Split authority: Avoid placing the MFA server only in the cloud region hosting the most applications, because a regional outage would then block on-premises staff too.
- Data residency: Confirm that enrollment data, logs and backups stay in agreed locations, since DORA Article 30(2) requires contracts to state where services are provided and data processed.
- Exit planning: Keep token data exportable in a documented format so that a move to another provider or location is possible under the exit strategy required by Article 28(8).
Ask the cloud and platform teams to show the failure path for each application, including what users see when the MFA link to the cloud region is unavailable.
Segmented networks, such as payment zones or enclaves with restricted egress, cannot reach the internet to validate push notifications or send SMS codes through external carriers. The second factor therefore has to work with on-premises components only. Hardware OTP tokens, FIDO2 keys and smartcards verified by a local MFA server fit these zones, while push and SMS depend on outbound paths that security teams often block by design.
- Push and SMS conflicts: Push notifications and SMS need outbound connections or external carriers, so they are usually not viable inside restricted egress zones.
- Local verification: Place the MFA server inside or adjacent to the segment, with only the required ports open from the VPN or jump host.
- Token supply: Plan hardware token procurement and seed import in advance, since the MFA server must hold the seeds it verifies against.
- Internal high availability: Run at least two nodes inside the segment, because restricted zones often cannot reach an outside failover site.
- Log export: Forward authentication logs through an approved internal path to the monitoring platform so activity remains auditable.
Confirm with the network security team which egress paths are permitted and whether any MFA component needs a change request before deployment.
VPNs are often the first place MFA is enforced, and a RADIUS outage can lock out remote staff who need to reach core systems during an incident. Failover design determines whether a single MFA node failure leaves remote access open with the second factor still enforced. The design should be tested before go-live, because RADIUS timeouts and retry settings vary by VPN vendor.
- Multiple RADIUS targets: Configure the VPN with at least two RADIUS servers in different hosts or sites, and verify the VPN's failover order and timeout values.
- Emergency access policy: Define, in writing and with the Qualified Individual or equivalent owner, the rule for temporary bypass and who may approve it, with logging of each use.
- Timeout testing: Measure how long a login waits when one RADIUS node stops responding, since long waits can look like outages to users.
- Logging: Send RADIUS and MFA logs to the same store so that each VPN session can be traced to a token and a decision.
- Vendor support: Ask the VPN vendor which RADIUS features and retry behaviors are supported for the firmware version in use.
Before go-live, run a failover test during a planned window and record the results as evidence for the change file.
How to roll out MFA across a financial institution in phases
A phased sequence moves MFA from a signed scope and documented exceptions to full coverage of remote access, administrator accounts, email, core systems and vendor logins, with evidence kept at each gate.
Confirm scope and written exception decisions
The Qualified Individual, with security, compliance and business owners, lists the information systems in scope and the users who access them, then decides which accounts cannot take MFA on day one. Any equivalent control must be approved in writing, so each exception gets an owner, a compensating control and a review point. The output is a signed scope document and an exception register that an examiner can read without interviews. Confirm with your counsel and examiners how they expect the register to be maintained.
Map inventory and user stores
Build an inventory of every login path: VPN, email, identity provider, administrator consoles, core banking and payment systems, cloud accounts and third-party portals. For each path, record which user store holds the identities (Active Directory, LDAP, FreeIPA, SQL or a SCIM source) and which integration method applies, such as RADIUS, a PAM module, a credential provider, or SAML or OIDC. The output is a coverage matrix that lists each system, its protocol, its user store, its owner and its current factor, and it becomes the baseline for every later gate.
Pilot MFA on VPN and administrator accounts
Start with remote access and privileged accounts, because these carry the highest exposure and have a small, known user population. Enroll a limited group, test push, OTP and hardware token flows against the privacyIDEA or Keycloak deployment, and confirm that the authentication events reach your log platform. Exercise the help desk on lockouts and lost devices during the pilot. The output is a pilot report that lists the enrolled users, the failed and successful logins, the defects found and the decisions made on each defect.
Build high availability and test failover
Deploy the MFA service and its dependencies across redundant nodes, and make sure the database and session state survive a node loss. Test each failure you can predict: one node down, the database failing over, the directory unreachable and the RADIUS or PAM path interrupted. Confirm how each integration behaves when the MFA service cannot answer, and document the fail-open or fail-closed decision for each system with its approval. The output is a tested failover record with dates, observed behavior and the remediation for every failed test.
Run enrollment and help desk processes
Define how users enroll each token type, how identity is verified before a token is issued or reset, how lost or stolen tokens are revoked, and how hardware tokens are shipped and tracked. Train the help desk on these steps and on the escalation path for suspected account takeover. Run enrollment in waves so the help desk volume stays manageable. The output is an approved enrollment and recovery procedure, enrollment reports showing completion by population, and a log of help desk actions that ties each reset to a verified request.
Expand to email, core and vendor accounts
Extend coverage in waves to email and collaboration, core and payment systems, and third-party and vendor access. For each wave, update the coverage matrix, apply the integration and the enrollment process from the earlier gates, and confirm that vendor accounts meet the same factor requirement as internal users. Where an exception remains, link it to the register and set a review date. The output is an updated coverage matrix that shows every in-scope system with its factor and the status of each remaining exception.
Monitor steady state and keep the evidence
After full coverage, review enrollment, failed logins, bypass use and configuration changes on a set schedule, and alert on anything that moves an account out of MFA. Keep configuration exports, change records, access review results and failover test records together so they can be produced for an examiner or an independent assessment. Confirm your retention periods with compliance counsel. The output is a recurring evidence pack and a monitoring dashboard that the Qualified Individual reviews and signs.
What examiners and auditors ask to see for MFA coverage
This table lists the evidence items examiners and auditors typically request for MFA at a covered financial institution, what each item proves and which component produces it. DeployOpen prepares these artifacts from the self-hosted stack, but independent assessors and examiners form any opinion on whether controls are adequate and operating.
| Evidence item | What it proves | Which component produces it |
|---|---|---|
| Coverage matrix of systems versus MFA status | Every VPN, email, admin and core banking entry point that an individual can use to reach information systems, and whether each requires a second factor or has a written exception | Inventory maintained by the institution, checked against privacyIDEA RADIUS, PAM and SAML integration configs and Keycloak client settings |
| MFA policy configuration exports | The rules that enforce MFA, including which user groups, applications and admin roles are covered and which token types are allowed | privacyIDEA policy export and Keycloak realm or authentication flow exports, captured under version control with change dates |
| Enrollment and token inventory | Which users hold which second factors, when each was enrolled and whether any tokens are disabled, lost or unassigned | privacyIDEA token list and enrollment records, including imported hardware token seed files; Keycloak required-action and credential records |
| Exception approvals in writing | That any system or user without MFA was approved by the Qualified Individual or equivalent owner, with a compensating control and an expiry date | Signed exception register kept by the institution; the MFA platform can enforce the exception group but cannot approve it |
| Authentication and admin audit logs, retained and reviewed | That logins, failures, MFA challenges and administrative changes are recorded, kept for the retention period and reviewed by someone accountable | privacyIDEA audit log and Keycloak admin and event logs forwarded to a SIEM such as Wazuh, with review tickets as proof of follow-up |
| Failover and recovery test results | That a failed MFA server or RADIUS path does not leave staff locked out or silently bypass MFA, and that the recovery procedure has been run | Test records from the high availability design, such as Keycloak cluster or database failover tests and privacyIDEA node outage drills, with dated results and fixes |
| Access reviews from midPoint | That the people with MFA-protected access are still entitled to it, with leavers removed and privileged roles recertified on a set cycle | midPoint certification campaign reports and provisioning logs, tied back to MFA enrollment and disablement actions |
What buyers ask about cost, effort and scope for financial MFA
What drives the cost of self-hosted MFA for a financial institution?
Cost depends on the scope you set, not on the license, because the core platforms are open source. The main components are:
- Servers and high availability: at least two nodes per MFA service, plus a database that the platform supports, all inside your own network.
- Hardware keys and tokens: FIDO2 keys, smartcards or OTP tokens bought per user, with replacements budgeted over time.
- Enrollment and help desk: staff time for enrollment, lost-token handling and lockout recovery, which recurs for the life of the service.
- Integration per system: each VPN, Windows logon, Linux PAM target, admin console and core application is separate work.
- Support subscriptions: vendor or partner support contracts, if you choose them.
Ask any quote to split one-time build work from recurring operations and to show the integration count it assumes.
Can our internal team implement MFA for financial systems on its own?
A capable internal team can implement it, but the question is whether it can sustain the platform and the evidence work alongside its other duties. Platform work covers identity source integration, token policy, high availability, backup, upgrades and testing of every login path. Your team must also own the operating model: enrollment, recovery, change control and log review. Confirm the team has experience with the chosen platform, the time to cover the upgrade cadence, and on-call coverage for a service that gates VPN and admin access. A partner can take fixed-scope build work in writing, while your staff keep operational ownership.
How long does an MFA rollout take at a bank or fintech?
Duration depends on how many systems you cover, how many identity sources you connect and how many users must enroll. Most programs phase the work: admin and remote access first, then email and core systems, then the wider workforce. Each phase needs its own testing and a fallback path so that a failure does not lock out staff. Ask any proposal for a phased plan with the systems in each phase and the exit criteria for each, and check it against your change calendar and any examination dates. No duration should be accepted without a written scope that lists those systems.
What must our bank supply before an MFA engagement starts?
The provider needs access and decisions from your side before design can begin. Prepare these items:
- Inventory of the systems in scope, including VPNs, email, admin consoles and core banking, with their authentication methods.
- Access to the directory the platform will read, such as LDAP or Active Directory, and an agreed account for it.
- Network paths, hosting location and change windows in your own cloud accounts, data centers or air-gapped network.
- A named owner for token policy, exception approvals and recovery procedures.
- Written approval of any equivalent control, since the FTC Safeguards Rule allows a Qualified Individual to approve one in writing.
Missing items usually show up as delays, so list them in the statement of work.
Does MFA alone satisfy PCI DSS or DORA requirements?
No. MFA is one control within a wider program. PCI DSS applies to entities that store, process or transmit cardholder data or could affect that environment, and it is assessed through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, issued by a Qualified Security Assessor or by the entity itself, depending on the case. DORA, Regulation (EU) 2022/2554, applies since 17 January 2025 and also requires an information register, exit strategies for ICT services and tested ICT risk management. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or attestations. Confirm with your assessor which controls it will test.
How should we handle service accounts and automation that cannot use MFA?
Service accounts and automated jobs cannot answer a prompt, so they should not be placed under interactive MFA. Instead, identify them, remove interactive login where possible, and protect them with other controls such as restricted source addresses, scoped permissions and vaulted credentials. Record each exception with an owner, a business reason and a review date, and have the Qualified Individual approve it in writing if the FTC Safeguards Rule applies to you. Ask any partner to list every non-interactive account in scope and to show how each is monitored and logged.
Which vendor or partner terms should we check in an MFA quote?
Ask for terms that match the scope and the regulatory duties. Check these points in writing:
- Where services are delivered and where data is processed, with advance notice of changes.
- Support hours, upgrade responsibility and how security patches are handled.
- Data return and exit assistance if the engagement ends.
- Who owns the configuration, runbooks and evidence at handover.
- Whether support is a separate retainer, since ongoing support, upgrades and testing are offered as retainers.
DeployOpen works on fixed-scope agreements with scope, deliverables and timelines agreed in writing before work starts, and does not publish a price list.
Questions to ask an implementation partner before signing
Start with the question that decides whether the project survives an examination: what evidence will you hand us at the end, and how is it organized for an examiner? Ask the partner to show, in writing, how they have prepared financial services environments for review, which controls they map to FTC Safeguards Rule 16 CFR 314.4(c) for MFA coverage, and what the configuration export, enrollment logs and exception records look like. Then ask for the written scope and the exception process. Every system not covered by MFA, including any service account or legacy application, should appear in the scope with a named owner and a written approval from the Qualified Individual where an equivalent control is used under 16 CFR 314.4(c)(5). A partner who cannot describe how an exception is raised, approved and reviewed is not ready for a regulated bank.
Next, test the high availability design. Ask how the privacyIDEA or Keycloak deployment behaves when the MFA service, its database or one site is down, and ask for the failover test plan and its results from a previous engagement, with client names withheld. For Keycloak, confirm the database supports the synchronous replication its high availability designs require, and confirm which of the three documented architectures is proposed. Ask how RADIUS and PAM fallback is handled for VPN and admin access, and who can override a lockout. On tokens and phishing resistance, ask which factors the partner will enable for administrators first, whether FIDO2 keys are included, and how service accounts that cannot answer a prompt are handled, for example through tightly scoped, separately monitored credentials.
Finally, settle contract and licensing terms before signing. Under DORA Article 30(2), if the institution is in scope, the contract should state where services are provided and data processed, give advance notice of changes, and cover data return on termination. Under Article 28(8), ask for a documented, tested exit plan for any ICT service supporting a critical or important function. Ask the partner to confirm the license of each component, since privacyIDEA is AGPLv3 and Keycloak is Apache-2.0, and have your counsel review the obligations that apply to modified AGPL code. Ask for the post-go-live retainer scope, the patch cadence for the Keycloak release line and the approval process for operator upgrades, and whether the retainer includes evidence refresh before each assessment.
