Financial services firms carry more identity obligations than almost any other sector, and attackers know that every identity gap ends in stolen money or data. Banks, insurers and payments firms must verify customers, authenticate payments, control privileged and machine access, and prove it to supervisors. This guide maps those identity controls to the main EU, UK and US rules: DORA, the PSD2 strong customer authentication standards and the PSD3 package, the new EU AML Regulation, the UK Money Laundering Regulations, NYDFS Part 500, the FTC Safeguards Rule, FFIEC guidance, PCI DSS and SOX. It is for security, identity and compliance teams who want one control set that satisfies several regimes.
Key takeaways
- Customer identity has two legal anchors: customer due diligence under AML law at onboarding, and strong customer authentication with dynamic linking for payments and account access.
- DORA turns access control into law: since 17 January 2025, EU financial entities must limit logical access to what approved functions need and implement strong authentication mechanisms (Article 9(4)(c) and (d)).
- US rules now name MFA for everyone: the FTC Safeguards Rule requires MFA for any individual accessing any information system, and NYDFS Part 500 has required the same since 1 November 2025, with narrow exceptions.
- Machine credentials cause the largest losses: the Capital One, Snowflake and Bybit incidents all turned a cloud role, a password without MFA or a hijacked session token into mass data theft or a $1.5 billion loss.
- Build one control set and map it: the same inventory, MFA, least privilege, logging and supplier controls answer DORA, NYDFS, the FTC rule, PCI DSS and SOX auditors, so map once and reuse the evidence.
Regulations and frameworks at a glance
Scope depends on licence, location and activity, so confirm applicability with your compliance function.
| Regulation / framework | Applies to | Identity-relevant obligations |
|---|---|---|
| EU DORA (Regulation (EU) 2022/2554) | EU financial entities; critical ICT third-party providers face direct oversight. Applies from 17 January 2025 (Article 64) | Access limited to approved functions and strong authentication (Article 9(4)); major incident reporting (Article 19); ICT third-party register (Article 28(3)) |
| PSD2 SCA standards (Delegated Regulation (EU) 2018/389) | Payment service providers. Applies from 14 September 2019 (Article 38) | Two or more independent elements, one-time codes, dynamic linking to amount and payee, credential protection |
| PSD3 and the Payment Services Regulation (EU) | Payment service providers, with some duties for platforms and telecoms providers | Provisional political agreement on 27 November 2025, according to William Fry: payee name checks, liability for some impersonation fraud, SCA retained. Check the final published text and dates |
| EU AML Regulation (EU) 2024/1624 | Obliged entities. Applies from 10 July 2027 (Article 90), with later dates for some entity types | Customer due diligence (Article 20); verification by documents or eID at assurance level substantial or high (Article 22(6)) |
| eIDAS 2 (Regulation (EU) 2024/1183) | Private relying parties that must use strong user authentication, including banking and financial services | Accept European Digital Identity Wallets on the user's request, no later than 36 months after the relevant implementing acts enter into force (Article 5f(2)) |
| UK Money Laundering Regulations 2017 and FCA rules | UK regulated firms | Identify and verify customers, ongoing monitoring (regulation 28); FCA operational resilience rules, with mapping and testing due by 31 March 2025 |
| NYDFS 23 NYCRR Part 500 | Entities licensed under New York banking, insurance or financial services law | MFA for any individual accessing any information system (500.12), asset inventory (500.13), 72-hour incident notice, annual certification by 15 April |
| FTC Safeguards Rule (16 CFR 314.4) | Financial institutions over which the FTC has jurisdiction under the Gramm-Leach-Bliley Act (314.1) | Least privilege, MFA for any individual accessing any information system, activity logging, service provider oversight, FTC notice within 30 days for events affecting 500 or more consumers |
| FFIEC authentication and access guidance | US financial institutions; the FDIC issued it to all the institutions it supervises | Risk assessment driving authentication for customers, employees, third parties and service accounts; MFA or controls of equivalent strength |
| SOX section 404 | US public companies | Management assessment of internal controls, with auditor attestation for larger filers; access to financial systems is part of the control environment auditors test |
| PCI DSS v4.0.1 | Entities that store, process or transmit card data | MFA for all access into the cardholder data environment (8.4.2), MFA for remote access (8.4.3), MFA that cannot be bypassed (8.5), management and review of system and application accounts (7.2.5, 8.6) |
For a cross-sector view of the same rules, see the Identity Security Regulatory Map.
Customer identity
Customer identity is regulated at three moments: joining, logging in or paying, and recovering access. Each is also where fraud concentrates.
Onboarding and customer due diligence
The EU AML Regulation sets out the due diligence measures obliged entities must apply, including identifying and verifying the customer, identifying beneficial owners, screening for targeted financial sanctions, ongoing monitoring and verifying that anyone acting on the customer's behalf is authorised to do so (Article 20(1)). Identity can be verified from an identity document plus reliable independent sources, or through electronic identification means at eIDAS assurance level substantial or high (Article 22(6)). UK regulation 28 similarly requires identification and verification and allows a secure electronic identification process. See the Identity Proofing and KYC Guide and, for business customers and beneficial owners, the KYB Guide.
Strong customer authentication
The SCA standards are specific enough to serve as a baseline even outside the EU.
| SCA requirement | What the standard says | Identity design implication |
|---|---|---|
| Two or more elements (Article 4) | Authentication uses two or more of knowledge, possession and inherence and produces an authentication code accepted only once | Prefer device-bound credentials such as passkeys |
| Failed attempts and timeouts (Article 4(3)) | No more than five consecutive failed attempts before a block; no more than 5 minutes of inactivity after login | Set lockout and idle limits centrally |
| Dynamic linking (Article 5) | For remote payments, the payer sees the amount and payee, the code is specific to both, and any change invalidates it | Bind approval to transaction details so relayed or altered payments fail |
| Independence of elements (Article 9) | Breach of one element must not compromise the others; extra measures where a multi-purpose device such as a phone is used | Use secure execution environments and app integrity checks on mobile |
| Transaction risk analysis (Articles 18 and 21) | Exemption only where real-time risk analysis finds no abnormal behaviour, device, malware or location signals; fraud rates monitored at least quarterly | Feed identity and device signals to the fraud engine |
| Credential protection (Articles 22 to 24) | Credentials masked, not stored in plain text, created and associated with the user in secure environments; remote binding uses SCA | Treat device enrolment and credential reset as high-risk events that need SCA |
SMS one-time codes still appear in many SCA flows. NYDFS guidance, as summarised by Hogan Lovells, recommends token-based MFA over push or text-based methods because of human error and SIM swapping. See the MFA Guide.
Fraud, recovery and digital identity wallets
- Fraud signals: combine identity, device and behavioural signals with transaction monitoring. According to William Fry, the PSD3 agreement adds payee name checks and refunds for customers tricked by someone posing as the provider's staff, subject to conditions. See the Authorised Push Payment (APP) Fraud Guide.
- Recovery: the SCA standards require a secure procedure for regaining use of a blocked instrument (Article 4(4)). Re-proof customers for high-value recovery instead of relying on SMS or email links. See the Account Recovery and Help Desk Security Guide.
- Digital identity wallets: eIDAS 2 Article 5f(2) will require banks to accept European Digital Identity Wallets on the user's request (micro and small enterprises are excluded). See the Digital Identity Wallets Guide.
Workforce and privileged access
- MFA everywhere: the FTC Safeguards Rule requires MFA for any individual accessing any information system, unless the Qualified Individual approves equivalent or stronger controls in writing (314.4(c)(5)). NYDFS Part 500 applies the same breadth from 1 November 2025; a CISO may approve reasonably equivalent controls, reviewed at least annually.
- Phishing resistance: NYDFS's October 2024 letter on AI risks, quoted by Epstein Becker Green, suggests firms consider avoiding authentication via SMS, voice or video and using "digital-based certificates and physical security keys". See the Phishing-Resistant MFA Guide.
- Least privilege and segregation of duties: DORA requires access limited to legitimate and approved functions (Article 9(4)(c)), and the FTC rule requires limiting users to the customer information they need (314.4(c)(1)). Separate payment initiation, approval and release. See the Segregation of Duties Guide.
- Just-in-time privilege: remove standing administrator rights on production, payments and trading systems; grant time-bound elevation with approval and session recording. See the Privileged Access Management Guide.
- Bulk data access in support tools: the Coinbase Insider Breach 2025 involved bribed overseas support staff; The Register reported 69,461 users notified. Rate-limit lookups and mask data by default. See the Insider Threat and Identity Guide.
Non-human identities
Service accounts, cloud roles, API keys and pipeline tokens are in scope of the same rules. The FFIEC guidance explicitly covers service accounts, according to the FDIC's summary, and PCI DSS requires system and application accounts to be reviewed periodically (7.2.5.1) and their passwords protected against misuse (8.6.3).
- Cloud roles: in the Capital One Breach 2019, an attacker obtained temporary credentials for a web application firewall's cloud role and copied data on about 100 million people in the US and 6 million in Canada. The OCC fined Capital One $80 million in 2020. See the Cloud PAM and CIEM Guide.
- Developer and pipeline credentials: in the Bybit Hack 2025, attackers compromised a supplier developer's laptop and, according to Safe{Wallet}, hijacked AWS session tokens to get around MFA, leading to a theft the FBI puts at about $1.5 billion. See the CI/CD Pipeline Identity Security Guide.
- Data platform logins: in the Snowflake Breach 2024, Santander was among about 165 notified organisations. Mandiant attributed the attackers' success to no MFA, credentials not rotated and no network allow lists.
- Open banking and API clients: the SCA standards require providers to identify themselves to each other with qualified certificates for electronic seals or website authentication (Article 34). Bind API clients to certificates or keys instead of shared secrets. See the OAuth 2.0 and OpenID Connect Guide.
- Secrets and rotation: vault keys and tokens, rotate them, and give every non-human identity a named owner. See the Secrets Management Guide.
Third parties
Outsourcing does not move accountability. DORA says financial entities using ICT services "remain fully responsible" for their obligations (Article 28(1)(a)), and the FCA states that the UK critical third parties regime does not change firms' accountability for operational resilience. Identity is where third-party risk becomes real: supplier remote access, SaaS integrations holding OAuth tokens and managed service providers with admin rights.
| Rule | Third-party obligation | Identity control that provides evidence |
|---|---|---|
| DORA Article 28(3) | Register of information on all ICT third-party contractual arrangements, available to the supervisor on request | Link each register entry to the accounts, tokens and integrations the supplier holds |
| DORA Article 30 | Key contractual provisions for ICT services | Contract clauses on MFA, logging, access revocation and incident notice |
| FTC Safeguards Rule 314.4(f) | Select capable providers, require safeguards by contract, assess them periodically by risk | Periodic review of supplier access and its continued need |
| NYDFS Part 500 (500.11) | Third-party service provider policies; Epstein Becker Green notes the FAQs say relying on a provider's own certification is not enough | Due diligence on the provider's identity controls, not just a questionnaire |
| PCI DSS 8.4.3 | MFA for remote access from outside the network, including third-party and vendor access | Vendor access through a broker with MFA and session recording |
See the Third-Party Access Guide and the SaaS and OAuth App Governance Guide.
AI agents in financial services
AI agents that answer customers, reconcile accounts or initiate payments are non-human identities acting with delegated authority, so the controls above apply, plus a few specific to agents.
- Delegated, scoped authority: give each agent its own identity and credentials, scoped to the task and the customer it acts for. OWASP's Top 10 for Agentic Applications lists Identity and Privilege Abuse (ASI03) and Tool Misuse and Exploitation (ASI02) as top risks.
- Human approval for material actions: OWASP recommends requiring human approval for high-privilege or irreversible actions. For payments, an agent may prepare but not release a transfer above a set threshold.
- Attribution and logging: record which agent acted, for whom and with what authority, to meet FTC logging (314.4(c)(8)) and audit needs.
- High-risk AI uses: the EU AI Act lists creditworthiness assessment and credit scoring (excluding fraud detection) and risk assessment and pricing for life and health insurance as high-risk uses (listed in Annex III). The European Commission says rules for these Annex III areas apply from 2 December 2027 following the AI Omnibus agreement.
See the Agentic Commerce Identity Guide and the Agentic AI Compliance Guide.
Detection and monitoring
Several rules require monitoring outright: the FTC rule requires controls "designed to monitor and log the activity of authorized users" (314.4(c)(8)), PCI DSS requires audit logs of all actions by administrative accounts including interactive use of application or system accounts (10.2.1.2),. NYDFS requires notice within 72 hours of determining that a cybersecurity incident has occurred, according to Epstein Becker Green.
- Customers: new device plus payee change, rapid credential resets and SIM swap signals before high-value payments.
- Workforce: MFA fatigue, new MFA device registrations, out-of-window elevation and bulk record lookups.
- Non-human identities: interactive service account logins, cloud roles reading new data stores and tokens used from new networks.
- Third parties: supplier sessions outside contracted hours and OAuth integrations pulling unusual data volumes.
See the ITDR Guide.
Framework mapping
Control IDs were checked against NIST CSF 2.0, the SP 800-53 Rev. 5 catalogue, published ISO/IEC 27001:2022 Annex A lists, CIS Controls v8.1 and the OWASP NHI Top 10 (2025).
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP |
|---|---|---|---|---|---|
| Customer identity proofing | PR.AA-02 | IA-12 | 5.16 | n/a | n/a |
| MFA for staff, admins and remote access | PR.AA-03 | IA-02, IA-02(01), AC-17 | 8.5 | 6.3, 6.4, 6.5 | NHI4 (insecure authentication) |
| Least privilege and segregation of duties | PR.AA-05 | AC-05, AC-06, AC-06(05) | 5.3, 5.15, 8.2 | 5.4, 6.8 | NHI5 (overprivileged NHI) |
| Account lifecycle and reviews | PR.AA-01, PR.AA-05 | AC-02, AC-02(03) | 5.16, 5.18 | 5.3, 6.1, 6.2 | NHI1 (improper offboarding) |
| Service accounts and secrets | PR.AA-01, ID.AM-02 | IA-05, IA-09, CM-08 | 5.17 | 5.5 | NHI2, NHI7 |
| Third-party and supplier access | GV.SC-07, DE.CM-06 | SA-09, SR-06, PS-07 | 5.19, 5.20, 5.22 | 15.4 | NHI3 (vulnerable third-party NHI) |
| Logging and monitoring of identity activity | DE.CM-03 | AU-06, AC-06(09), AC-02(12), SI-04 | 8.15, 8.16 | Control 8 | NHI10 (human use of NHI) |
| AI agent authority and approval | PR.AA-05 | AC-06 | 5.15, 8.2 | Control 6 | ASI02, ASI03 (Agentic Top 10) |
Common failure patterns
- Workload roles with data-wide read access: the core lesson of the Capital One Breach 2019.
- MFA on staff but not on data platforms and service logins: single-factor passwords on cloud data services, often held by contractors, were enough in the Snowflake Breach 2024.
- Trusting a supplier's session tokens: MFA at login does not help once a session token is stolen, as the Bybit Hack 2025 showed.
- Unlimited lookups in support and back-office tools: insiders and bribed contractors can export customer records one screen at a time, as in the Coinbase Insider Breach 2025.
- SMS as the only second factor: NYDFS has highlighted SIM swapping and deepfake risks to SMS and voice checks.
- Compliance silos: separate DORA, PCI and SOX projects build conflicting access reviews.
- Service accounts outside reviews: PCI DSS 7.2.5.1 requires system and application accounts to be reviewed, yet many programmes certify only humans.
- Agents with a human's full rights: an agent using an employee's session or a shared key cannot be scoped or attributed.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Share of workforce and third-party logins using phishing-resistant MFA | Exposure to phishing, push fatigue and SIM swap | Up |
| Information systems without MFA or an approved compensating control | Readiness for NYDFS 500.12 and FTC 314.4(c)(5) | Down to zero |
| Standing privileged accounts on payment and production systems | Progress towards just-in-time access | Down |
| Non-human identities with a named owner and recorded purpose | Inventory quality for DORA, NYDFS 500.13 and PCI 7.2.5 | Up |
| Secrets older than the rotation policy allows | Exposure to long-lived credential theft | Down |
| Suppliers in the DORA register with mapped access paths | Third-party identity visibility | Up |
| Customer payments approved with device-bound credentials | Move away from SMS for SCA | Up |
| Time from leaver or supplier exit to full access removal | Offboarding effectiveness, human and machine | Down |
Implementation roadmap
| Phase | Focus | Outputs |
|---|---|---|
| First 30 days | Scope and visibility | Applicable rules by entity; one mapped control set; inventory of privileged, service and supplier accounts; systems without MFA |
| Days 31 to 90 | Close the largest gaps | MFA or a documented compensating control on every system; hardware keys for admin and payment roles; NHI owners; bulk-access limits |
| Days 91 to 180 | Reduce standing privilege and secrets | Just-in-time elevation; secrets vaulted and rotated; cloud roles right-sized; supplier access brokered and linked to the DORA register |
| Beyond 180 days | Customer and agent maturity | Passkeys for customer SCA; wallet acceptance plan; AI agent identities with approval thresholds; continuous identity detection |
Practitioner checklist
- Map identity controls once to DORA, PSD2 SCA, AML rules, NYDFS, the FTC rule, PCI DSS and SOX as they apply, and reuse the evidence.
- Proof customers to the risk of the product and record how identity was verified (document or eID).
- Meet SCA with dynamic linking and move customers towards device-bound credentials and passkeys.
- Enforce MFA on every information system, with hardware keys for privileged, payment and treasury roles.
- Remove standing admin rights; use just-in-time elevation, session recording and segregation of duties.
- Limit and monitor bulk customer data access in support and back-office tools.
- Inventory every service account, cloud role, API key and token with an owner, purpose and rotation date.
- Link the DORA register (or equivalent supplier list) to the accounts and tokens each supplier holds.
- Give each AI agent its own scoped identity and require human approval for material actions.
- Detect identity incidents fast enough to meet the 72-hour NYDFS and other reporting clocks.
Standards and references
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience (DORA)
- EUR-Lex: Commission Delegated Regulation (EU) 2018/389 on strong customer authentication
- EUR-Lex: Regulation (EU) 2024/1624 on anti-money laundering
- EUR-Lex: Regulation (EU) 2024/1183 establishing the European Digital Identity Framework
- Cornell LII: 16 CFR 314.4, FTC Safeguards Rule elements
- FDIC: FFIEC Authentication and Access to Financial Institution Services and Systems
- Hogan Lovells: NYDFS amended Part 500 requirements effective 1 November 2025
- PCI Security Standards Council: PCI DSS v4.0.1 document library
- legislation.gov.uk: Money Laundering Regulations 2017, regulation 28
- FCA: Operational resilience
- NIST: Cybersecurity Framework 2.0
- OWASP: Non-Human Identities Top 10 (2025)
Also read: William Fry on PSR and PSD3, Epstein Becker Green on NYDFS, Schellman on PCI DSS MFA, NIST SP 800-53 Rev. 5, OWASP Agentic Top 10.
This guide summarises identity-related obligations in financial services regulation for security practitioners and is not legal advice. Related NHI Mgmt Group resources: Identity Security Regulatory Map · Identity Fraud Prevention Guide · Privileged Access Management Guide · Third-Party Access Guide