What is the difference between Strong Customer Authentication and PCI DSS for payment security?

Why This Matters for Security Teams

strong customer authentication and PCI DSS are often mentioned together, but they solve different problems. SCA is a transaction-time authentication requirement that helps reduce fraud for qualifying payments in the EEA, while PCI DSS governs how cardholder data and payment environments are protected more broadly. Teams that blur the two usually create gaps in either checkout experience, fraud controls, or payment infrastructure hardening.

The practical risk is that a compliant authentication step can still sit on top of weak environment controls, exposed secrets, or poor segmentation. NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which matters because payment systems often rely on API keys, service accounts, and tokens behind the scenes. That is why payment security reviews should separate customer authentication from backend protection, then map both to PCI DSS v4.0 and the broader identity guidance in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

In practice, many security teams discover the difference only after a payment flow fails an audit or a fraud review exposes controls that were assumed to be interchangeable.

How It Works in Practice

SCA is about proving the payer is genuinely authorised at the moment of the transaction. In practice, that usually means applying at least two independent factors from knowledge, possession, and inherence for qualifying card payments under the EEA rules. PCI DSS, by contrast, is about protecting the payment ecosystem itself: storing less card data, encrypting what must be retained, restricting access, monitoring activity, and hardening systems that touch cardholder data. The two controls can coexist, but one does not replace the other.

A useful way to operationalise the difference is to treat SCA as a fraud and customer-authentication control, and PCI DSS as an environment and data-protection control. That distinction matters when payment flows involve third parties, gateways, or embedded checkout components. For example, a merchant might use SCA at the edge while still needing PCI-scoped controls for logs, webhook handlers, service accounts, and API integrations. The PCI Security Standards Council documents the cardholder-data obligations, while NIST SP 800-53 Rev. 5 is useful for translating those obligations into access control, logging, and configuration management practices.

• SCA should be validated where the transaction occurs, not assumed because the session is already authenticated.
• PCI DSS scope should be mapped from card data flow, system boundaries, and trust relationships.
• Secrets used by payment services should be rotated and protected because backend compromise can bypass customer-facing checks.
• Service-to-service identity should be reviewed separately from customer identity.

NHIMG’s Ultimate Guide to NHIs is relevant here because payment platforms depend heavily on non-human identities that can silently expand PCI scope or create fraud exposure. These controls tend to break down when payment architecture is fragmented across multiple processors, microservices, and outsourced integrations because no single team owns the full transaction path.

Common Variations and Edge Cases

Tighter authentication often increases checkout friction, requiring organisations to balance fraud reduction against conversion loss and regulatory scope. That tradeoff becomes sharper when payments span the EEA and non-EEA markets, because SCA may apply only to certain transactions while PCI DSS still governs the underlying environment wherever card data is handled.

There is no universal standard for every exemption path yet, so current guidance suggests treating exemption use as a risk decision rather than a blanket policy. Merchant-initiated transactions, recurring billing, and low-risk payments can trigger different SCA treatment, but PCI DSS obligations around storage, access, and monitoring remain relevant if card data or sensitive authentication data is still present. The same is true when payment orchestration platforms, fraud vendors, or tokenisation services are involved: reduced customer friction does not remove the need for scoped controls.

For governance teams, the cleanest rule is to document which control answers which question. SCA answers, "Was the payer authenticated for this transaction?" PCI DSS answers, "Is the cardholder data environment protected end to end?" When that distinction is missed, organisations either over-engineer the checkout flow or under-protect the payment stack. The NHI angle also matters because a mismanaged service credential can expose payment data even if the customer authentication step was perfectly compliant.

Related resources from NHI Mgmt Group

• What is the difference between strong customer authentication and ordinary MFA?
• What is the difference between strong authentication and least privilege in cloud security?
• What is the difference between customer due diligence and strong customer authentication here?
• What is the difference between strong client authentication and least privilege?