PSD2 strong customer authentication: what the audit misses and attackers exploit
Julian ThorneApril 29, 2026
Key takeaways
PSD2 SCA audits verify that two authentication factors exist but do not check whether those factors can be bypassed by reaching the authentication endpoint through an undocumented subdomain or legacy staging API.
In Vulnox assessments of payment service providers, roughly one in three environments had at least one open banking API endpoint reachable from the public internet that the internal team did not know existed.
SCA exemptions for low-value transactions (under EUR 30) and trusted beneficiaries create a logic layer that attackers probe directly. The exemption decision engine is rarely included in penetration testing scope.
SMS OTP, still the most common possession factor deployed for SCA, fails the EBA''s independence requirement when the same device receives both the transaction notification and the one-time code.
The EBA''s Regulatory Technical Standards for strong authentication do not require PSPs to demonstrate what their authentication surface looks like from outside the perimeter. That gap is structural, not incidental.
A falsifiable prediction: by 2027, at least one high-profile PSD2 enforcement action in the EU will cite attacker exploitation of an SCA exemption logic flaw rather than a missing authentication factor.
TL;DR
PSD2 strong customer authentication is the right requirement enforced against the wrong threat model. Auditors check that two factors exist. Attackers check whether the endpoint handling those factors is reachable from a forgotten subdomain, whether the exemption logic can be fed crafted inputs, and whether the possession factor actually lives on a separate channel. The EBA''s RTS does not require PSPs to answer those questions. Most do not answer them voluntarily.
The audit passed. The endpoint was still live.
A mid-sized payments fintech operating across six EU markets completed its PSD2 SCA audit in Q3 2024. Clean report. The auditor confirmed two independent factors, documented exemption logic for recurring transactions, reviewed the OAuth 2.0 configuration for its open banking API. Two weeks after the report was filed, a Vulnox external assessment found a staging version of the same API still running on a subdomain that had not been decommissioned after a platform migration eight months earlier. The staging environment accepted authentication requests. It did not enforce rate limiting. It did not log to the production SIEM. The possession factor check — the SMS OTP — was present but routed through a test gateway with a shared API key visible in a public GitHub repository from a contractor commit in 2022.
The audit was not wrong. The auditor checked what the standard requires checking. The problem is that PSD2''s strong customer authentication requirements are written entirely around what the authentication system does internally. Nothing in the EBA''s Regulatory Technical Standards requires a PSP to verify what their authentication surface looks like from outside the perimeter. That is not a criticism of the auditor. It is a structural gap in the framework.
What the EBA RTS actually requires versus what attackers actually do
The EBA Regulatory Technical Standards under PSD2 Article 98 require that strong customer authentication use at least two independent elements from three categories: something the user knows, something the user possesses, and something the user inherits. Those elements must be independent — compromise of one must not allow derivation of another. The transaction must be dynamically linked to the payer, the payee, and the amount, so a replay of one transaction cannot authorize a different one. These are meaningful requirements. They address the authentication mechanism correctly.
What they do not address is the attack surface through which that mechanism is reached. The RTS assumes a single, known, controlled API surface. It has no provisions requiring PSPs to enumerate all endpoints where authentication is handled, to verify that staging and legacy environments have been decommissioned, to confirm that exemption decision logic is included in security testing scope, or to assess whether the channel delivering the possession factor is actually separate from the channel delivering the transaction notification.
Attackers do not read audit reports. They run subdomain enumeration tools. They probe authentication endpoints for rate limiting behaviour. They feed crafted transaction parameters to exemption engines looking for inputs that trigger the low-risk pathway without meeting its actual criteria. They test whether the SMS OTP and the transaction push notification both arrive on the same device through the same application — which, if they do, means compromise of the device collapses two factors into one.
Example
In one Vulnox engagement with a payment initiation service provider operating under PSD2, passive DNS reconnaissance identified six subdomains associated with the PSP''s authentication infrastructure. Two were active production systems known to the internal team. Three were decommissioned CDN nodes with no authentication functionality. One was a legacy version of the ASPSP-facing API that had been replaced in a platform upgrade but never taken down. That endpoint accepted the same OAuth token format as the current API. It did not enforce the dynamic linking requirement. The internal team had not included it in the previous penetration test because the test scope had been defined from an internal asset inventory that was eight months out of date.
Subdomain enumeration for payment service providers yields a different profile than for general SaaS companies. PSPs tend to accumulate authentication-adjacent subdomains through three vectors: banking partner integrations that provision dedicated subdomains for API routing; platform migrations where the legacy API is kept live for backward compatibility with slower-moving partners; and white-label deployments where a parent PSP''s authentication infrastructure is fronted by partner-branded subdomains that may have separate TLS certificates and separate logging pipelines. Each of these vectors creates potential gaps between the audit scope and the live attack surface.
What the data shows from PSP assessments
Assessment base: Vulnox external attack surface assessments of payment service providers, 2023-2025
Undocumented authentication endpoints in one in three PSP environments
Across Vulnox external assessments of payment service providers conducted between 2023 and 2025, roughly one in three environments had at least one authentication-related endpoint reachable from the public internet that was not included in the client''s asset inventory. The most common source was legacy open banking API versions retained for partner compatibility. The second most common was developer or staging environments where SCA enforcement was intentionally weakened to allow testing without triggering real possession factor challenges.
Every client that went into these assessments believed their SCA surface was fully inventoried. The belief was reasonable — they had internal asset management processes. The gap was not in the process design but in how asset inventories are populated. Internal teams define scope based on what was deliberately deployed. Passive DNS reconnaissance finds what was incrementally accumulated and never formally catalogued.
SCA exemption logic excluded from penetration test scope in the majority of engagements
When Vulnox reviewed prior penetration test reports provided by PSP clients, the exemption decision engine — the component that determines whether a given transaction qualifies for a low-value, trusted beneficiary, or low-risk exemption — was outside the test scope in most cases. The typical explanation given by the client was that the exemption engine was a business logic component, not an authentication component, and therefore fell outside the security team''s purview.
The exemption engine is the component that decides whether strong authentication is required at all. An attacker who can influence its inputs can route transactions through the unauthenticated pathway without touching the SCA factors at all. The business logic classification is accurate and counterproductive simultaneously.
Same-device possession factor collapse in SMS OTP implementations
In environments where SMS OTP was the primary possession factor, a recurring configuration pattern placed both the banking application and the SMS receiver on the same device, with no requirement for the user to authenticate the device separately. The transaction notification arrived in the banking app. The OTP arrived via SMS on the same device. The EBA''s RTS requirement for factor independence was technically met — knowledge is different from possession — but practically undermined because compromise of the device collapsed both channels into one.
This is the gap between the letter of the independence requirement and its operational intent. The RTS says the factors must be independent in design. It does not require that the delivery channels be independent. Auditors checking the design find compliance. An attacker who has achieved persistent access to a user''s device finds a single point of control over both factors.
Open banking API credentials in public repositories
In three separate PSP engagements, passive OSINT — specifically searching code repositories for strings matching the client''s domain and known API key formats — identified valid or recently valid credentials for open banking API endpoints. In two cases the credentials were committed by contractors working on partner integrations. In one case they were in a public configuration example in a partner''s GitHub repository, not the PSP''s own code.
PSPs tend to audit their own repositories. They do not routinely audit their partners'' repositories or contractor commit histories. The credential that enables API-level access to an SCA endpoint may not live in a system the PSP controls or monitors.
The organisation with stronger SCA may have a larger exploitable surface
Common belief
Investing in stronger SCA implementation — hardware tokens, biometrics, out-of-band push authentication — reduces an organisation''s PSD2 risk profile. More authentication strength equals lower exposure.
What we found
In Vulnox assessments of PSPs that had made recent investments in upgrading from SMS OTP to app-based push authentication, the post-upgrade environments consistently had more authentication-adjacent endpoints discoverable via passive DNS than the pre-upgrade environments, because the SMS infrastructure was retained as a fallback rather than decommissioned. The attack surface grew. The main authentication pathway got stronger. The retained SMS pathway remained at its prior security level and in several cases had less monitoring applied to it than before the upgrade, because attention had shifted to the new implementation.
This is true for the specific attack vector the authentication mechanism defends against: an attacker attempting to impersonate a legitimate user at a known authentication endpoint. It is not true for the attack vectors the mechanism creates.
More sophisticated SCA implementations typically involve more infrastructure: dedicated hardware token provisioning services, biometric processing backends, push notification delivery pipelines, device attestation endpoints, and separate fallback authentication paths for device loss scenarios. Each component in that infrastructure is an additional attack surface. Each has its own subdomain, its own API, its own credential set, and its own update and decommissioning lifecycle.
A PSP running SMS OTP has one authentication channel to secure and inventory. A PSP running a hybrid of FIDO2 hardware keys, software-based OTP via an authenticator app, SMS fallback, and out-of-band push notifications for high-value transactions has four or five. The security of each component matters, but so does whether the total set of endpoints handling that authentication flow has been enumerated and assessed.
What the external exposure numbers look like
One in three PSP environments assessed by Vulnox contained at least one authentication endpoint not present in the client''s internal asset inventory
These were not trivial gaps. In each case, the undocumented endpoint accepted the same credential formats as production systems. Vulnox assessment data, 2023-2025.
In 2024, the EBA published findings from its review of SCA implementation across EU payment service providers, noting that a significant proportion of PSPs were applying transaction risk analysis exemptions in ways inconsistent with the RTS requirements
The EBA review focused on exemption logic applied to transaction values and frequency. It did not assess whether exemption decision engines were included in security testing scope. Source: EBA consumer trends report 2024.
SIM swap fraud affecting SMS OTP-based SCA increased materially across European markets between 2022 and 2024
Europol Operation Spoofer and subsequent national-level enforcement actions documented organised SIM swap campaigns targeting specifically the SMS-based authentication step in online banking and payment initiation flows. Source: Europol IOCTA 2024.
Where PSD2 SCA assessments consistently miss
External asset enumeration
PSD2 audits define scope based on the systems the PSP submits for review. Passive DNS enumeration, certificate transparency log analysis, and OSINT across code repositories are not standard components of a PSD2 SCA audit. The result is that the audit verifies the security of the systems the PSP knows about and says nothing about the systems it does not.
Exemption engine security testing
The component that determines whether SCA applies to a given transaction is classified as business logic rather than authentication infrastructure. Security teams test authentication. Business analysts review exemption rules. Neither group typically tests the exemption engine under adversarial conditions — specifically, testing whether crafted transaction parameters can manipulate the risk score into the exemption pathway.
Partner and contractor credential hygiene
PSPs maintain credential management processes for their own systems. They generally do not extend those processes to credentials held by partners, contractors, or third-party integrators. A credential committed to a partner''s repository grants the same API access as a credential managed internally. The audit boundary stops at the PSP''s own systems.
Fallback authentication surface
When PSPs upgrade their primary authentication mechanism, legacy fallback paths are typically retained rather than decommissioned. The audit and subsequent security testing focuses on the new primary path. The fallback path — often the prior-generation mechanism with weaker monitoring — remains live and reachable, assessed to the standard of when it was primary rather than the current standard.
Dynamic linking implementation under real load
The EBA RTS requires that authentication be dynamically linked to specific transaction parameters. This linkage is straightforward to verify in a controlled test environment with a single transaction. Under real load, implementations that rely on stateful session management or asynchronous event processing can introduce windows where the linkage validation degrades. Functional testing finds the mechanism. Load testing under adversarial conditions tests whether the mechanism holds.
What clients say going in, and what the data shows
We passed the SCA audit last quarter. Our authentication is compliant.
Root cause:The audit verified that the authentication mechanism meets the EBA''s design requirements. It did not verify whether the complete attack surface through which that mechanism is reached has been enumerated, whether exemption logic is hardened against adversarial inputs, or whether credential hygiene extends to partners and contractors. Passing an SCA audit answers one specific question correctly. It does not answer the questions attackers ask.
We use app-based push authentication with biometric confirmation. SMS OTP risk doesn''t apply to us.
Root cause:SMS OTP is typically retained as a fallback for device loss, onboarding, and accessibility scenarios. The primary pathway is stronger. The fallback pathway is still live. In several Vulnox assessments, the fallback pathway had less logging coverage than the primary pathway because monitoring configuration had been updated for the new implementation without revisiting fallback path monitoring. An attacker who can trigger the fallback pathway — by simulating device loss at the authentication layer — accesses the weaker mechanism with less detection coverage.
Our open banking API is behind an API gateway with rate limiting and authentication. Credential exposure is handled.
Root cause:The production API is protected. The question is whether it is the only endpoint accepting the same credential format. Staging environments, legacy API versions, partner integration endpoints, and white-label deployments provisioned on behalf of third parties are frequently outside the production API gateway. In three of the four Vulnox assessments where credentials were found in public repositories, the credentials were valid against endpoints that sat outside the monitored API gateway.
Where PSD2 SCA enforcement is heading
By 2027, at least one high-profile EBA or national competent authority enforcement action will cite attacker exploitation of an SCA exemption logic flaw, not a missing authentication factor, as the primary cause of a payment fraud incident at a regulated PSP.
Exemption logic is the most systematically undertested component in PSD2 SCA implementations. Fraud toolkits targeting PSD2-regulated markets are already probing exemption pathways — transaction chaining to stay below EUR 30 thresholds, manipulation of beneficiary trust scoring, and testing of recurring transaction exemptions with crafted payment sequences are documented in fraud pattern analysis from Europol and major card scheme security teams. The enforcement action has not happened yet because regulators are still building the attribution capability to distinguish exemption logic exploitation from standard fraud. That capability is being built.
Confidence: mediumIf no enforcement action citing exemption logic exploitation occurs by end of 2027 in any EU member state or EEA jurisdiction, the prediction is wrong. Observable leading signal: national competent authority guidance documents in 2025-2026 that specifically require exemption decision engines to be included in penetration testing scope.Within 18 months, subdomain-based access to legacy SCA infrastructure will be identified as the initial access vector in a publicly attributed payment fraud campaign targeting EU-regulated PSPs.
The pattern exists in the data from Vulnox assessments. Subdomain enumeration tooling has become commoditised and is routinely included in initial access broker playbooks. PSPs that have completed platform migrations in the past 24 months — a large cohort given the wave of open banking infrastructure upgrades driven by PSD2 implementation timelines — have the highest density of retained legacy endpoints. The only reason this has not been publicly attributed yet is that fraud investigations in the payments sector tend to attribute losses to account takeover generically rather than tracing the specific initial access vector.
Confidence: mediumA publicly attributed fraud campaign citing subdomain-based legacy API access as the initial vector. Observable leading signal: Europol or national financial intelligence unit advisories in 2025 specifically referencing legacy API exposure at PSPs as an emerging initial access pattern.
The RTS requirement that should exist and doesn''t
The EBA''s Regulatory Technical Standards for PSD2 strong customer authentication are a well-constructed set of requirements for the wrong problem scope. They are rigorous about authentication mechanism design — factor independence, dynamic linking, replay prevention. They are silent about authentication surface management. There is no RTS provision requiring PSPs to enumerate the full set of endpoints where authentication is handled, to include exemption logic in security testing, or to extend credential management practices to third-party integrators.
This is not an oversight. The RTS was written to standardise what SCA must do. It was not written to specify how PSPs must assess whether their SCA implementation is reachable by adversaries in ways they did not intend. That second question has historically been left to general information security governance, which sits outside PSD2''s scope.
My position is that this scope boundary is wrong and that the EBA should amend the RTS to require PSPs to conduct external attack surface assessments covering all authentication-related endpoints as part of their ongoing SCA compliance program. Not a one-time penetration test of the production system, but a continuous external enumeration discipline that would catch legacy API retention, contractor credential exposure, and partner subdomain proliferation before they become fraud pathways.
The strongest counterargument is that this would expand PSD2 compliance costs significantly for smaller PSPs and payment initiation service providers that are already operating under tight margins. That concern is legitimate. The cost of external attack surface assessment has come down materially with tooling improvements over the past three years, but it is not zero, and mandating it without a proportionality mechanism would create a barrier for smaller players.
Counterargument
The proportionality concern is real but does not change the analysis on risk. The alternative — leaving external surface assessment outside PSD2 scope — means the subset of PSPs that do not conduct it voluntarily will continue to carry unknown authentication exposure that neither they nor their auditors are measuring. The enforcement action that follows a major fraud incident attributable to legacy API exposure will be more disruptive to smaller PSPs than a compliance requirement to assess their external surface would have been.
One thing to do before the end of the week
Run passive DNS enumeration against your own domain and every subdomain associated with your open banking infrastructure. Tools like Amass or SecurityTrails will return results in under an hour. Compare the output against your internal asset inventory. Flag every subdomain that appears in the enumeration result but not in your inventory, and specifically check whether any of those untracked subdomains resolve to an IP that accepts HTTP or HTTPS requests.
This is not a full external assessment. It is the first question an attacker asks about your authentication surface, and it takes less time to answer than the meeting you will schedule after a fraud incident to find out where the access came from.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
comprehensive vulnerability assessmentsNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideOWASP Web Security Testing Guide
OWASP web security testingPCI Security Standards Council
PCI security standards council
Frequently Asked Questions
What does PSD2 strong customer authentication actually require under the EBA RTS?
The EBA RTS requires at least two independent authentication factors from knowledge, possession, and inherence categories, plus dynamic linking of the authentication to specific transaction parameters. It does not require PSPs to enumerate all endpoints handling authentication, include exemption logic in security testing, or verify that legacy API versions have been decommissioned.
How do attackers exploit SCA exemption logic in PSD2 payment flows?
Attackers probe the exemption decision engine with crafted transaction parameters to trigger low-value or low-risk exemption pathways without meeting their actual criteria. Transaction chaining below EUR 30 thresholds, manipulation of trusted beneficiary scoring, and crafted recurring transaction sequences are documented techniques. The exemption engine is rarely included in penetration test scope.
Why does SMS OTP fail the PSD2 factor independence requirement in practice?
SMS OTP technically satisfies the independence requirement because knowledge and possession are different factor categories. In practice, independence is undermined when both the transaction notification and the OTP arrive on the same device through the same channel. Compromise of the device collapses both factors into a single point of control, which is exactly what the independence requirement is designed to prevent.
What does a PSD2 external attack surface assessment find that an SCA audit misses?
External assessments routinely find legacy open banking API versions retained after platform migrations, staging environments with weakened SCA enforcement, partner-branded subdomains outside the production API gateway, and valid credentials in contractor or partner code repositories. In Vulnox assessments of PSPs, roughly one in three environments contained at least one authentication endpoint not in the internal asset inventory.
How should a payment service provider test its SCA exemption logic for security?
Exemption decision engines should be tested under adversarial conditions as part of penetration testing scope, not excluded as business logic. Testing should include crafted transaction parameters targeting threshold boundaries, frequency patterns that mimic recurring transaction exemption criteria, and beneficiary trust score manipulation. The test should be run against the live exemption engine, not a functional specification document.
What is the biggest open banking API security gap for PSD2 compliance?
The most consistently observed gap across PSP environments is undocumented API endpoints reachable from the public internet. These typically originate from legacy API versions, staging environments, and partner integration subdomains. These endpoints accept the same credential formats as production systems but sit outside monitoring pipelines and are not included in audit scope because they are not in the internal asset inventory.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.