Preparing for PCI DSS v4.0 MFA testing in Saudi Arabia is not only a documentation exercise. Many payment firms can show that multi-factor authentication is configured, yet cannot show evidence that it holds up when someone actively tries to defeat it. Gaps in device binding and transaction signing are then found late, often during the assessment by the Qualified Security Assessor (QSA).
This article describes four scenarios a bank, fintech or payment service provider can walk through internally: SIM swap, device clone, session hijack and push-notification interception. Each is designed to show whether Nafath binding, biometric checks and out-of-band transaction signing genuinely prevent account takeover.
A note on scope: PCI DSS is issued by the PCI Security Standards Council, and Saudi institutions also operate under SAMA requirements, including the SAMA Cyber Security Framework and the SAMA Counter-Fraud Framework. Confirm with your QSA which requirements apply to your cardholder data environment and how they expect MFA testing evidence to be presented. We do not cite a specific requirement number here because the mapping depends on your environment.
Start with the journeys, not the tools
MFA is rarely one control. In digital banking it is a chain: onboarding and identity proofing, device registration, login, step-up authentication, transaction signing and customer notification. A weakness at any link can undo the others.
Before testing, list each customer journey and the authentication factor at each step. Note where the factor is something the customer knows, has or is, and where one channel carries more than one factor. A single phone receiving the SMS code, the push prompt and the banking app is a common example of factors that are not truly independent.
Scenario 1: SIM swap
Objective: confirm that taking over a customer's phone number does not allow access to the account or approval of payments.
Walk through the following:
- Identify every flow that still accepts SMS or voice as a factor, including password reset, device re-registration and limit changes.
- Simulate a number transfer in a controlled environment and attempt each of those flows.
- Check whether the bank detects a recent SIM change and applies a cooling-off period or stronger verification.
- Confirm that re-binding a device requires a fresh Nafath authentication rather than an SMS code alone.
Typical gaps: recovery paths that fall back to SMS, and device re-registration that is weaker than first registration.
Scenario 2: Device clone
Objective: confirm that copying app data or emulating a registered device does not produce a trusted device.
- Restore app data, tokens or keys to a second device and attempt login.
- Run the app on an emulator or rooted device and observe whether integrity checks respond.
- Verify that the device binding key is stored in hardware-backed secure storage and cannot be exported.
- Check that biometric approval is tied to a cryptographic key on the device, not merely a local pass or fail flag that can be bypassed.
Typical gaps: bindings based on device identifiers that can be replayed, and biometric checks that only gate the user interface instead of releasing a signing key.
Scenario 3: Session hijack
Objective: confirm that a stolen session cannot be used to move money.
- Replay a captured session token from another device and network.
- Test token lifetime, rotation and revocation after logout, password change and device removal.
- Attempt a payment or beneficiary addition within a hijacked session and confirm that step-up authentication is still demanded.
- Check whether remote access tools or overlay behaviour on the customer device are detected.
Typical gaps: long-lived tokens, sessions that survive a device unbinding, and step-up prompts that can be skipped by calling the API directly.
Scenario 4: Push-notification interception and fatigue
Objective: confirm that a customer cannot be tricked or flooded into approving a fraudulent action.
- Trigger repeated approval prompts and observe whether the system rate-limits them.
- Review what the prompt shows. A signing request should display the payee, amount and purpose so the customer approves the transaction, not just a generic login.
- Test whether the approval is cryptographically bound to the transaction details, so that changing the amount or beneficiary after approval invalidates it.
- Check whether lock-screen previews expose one-time codes.
Typical gaps: generic "approve" prompts, no limit on repeated requests, and signing that is not bound to transaction content.
Record evidence as you go
An assessor will want to see what was tested, how, and what happened. For each scenario, keep:
- The journey and control under test.
- The steps performed and the environment used.
- The expected result and the actual result.
- Any defect raised, its owner and its remediation date.
Run these tests in a pre-production environment where possible. If live testing is unavoidable, limit it to agreed, safe scenarios and obtain approval first.
Prioritise by fraud impact and customer experience
Not every finding carries equal risk. A recovery path that bypasses Nafath matters more than a cosmetic prompt issue. Rank findings by how directly they enable account takeover, then weigh the customer impact of the fix. Stronger friction on high-value or high-risk actions is usually easier to defend than blanket friction on every login.
How we can help
Our Digital Banking and Payment Fraud Controls Review is an end-to-end review of fraud controls in mobile and internet banking, eKYC onboarding (Nafath), device binding, transaction signing and customer notifications. The review works in four stages: map customer journeys and their controls, threat-model fraud scenarios for each step, test controls through scenario walkthroughs, and recommend a prioritized roadmap with experience impact.
The deliverables are a journey-by-journey control assessment, fraud scenario test results and a remediation roadmap. The assessment takes 4–8 weeks and draws on SAMA CFF, SAMA CSF and PCI DSS.
With your approval we test in a pre-production environment, and live testing is limited to agreed, safe scenarios. The review focuses on fraud controls and does not include penetration testing, although it pairs well with our penetration testing service.
If you want to know how your binding and signing controls behave before the QSA tests them, this review is a practical place to begin.
