How to Test Nafath Device Binding Against PCI DSS 8.4.2

# How to Test Nafath Device-Binding and Transaction-Signing Controls Against PCI DSS v4.0 Requirement 8.4.2: The Four-Scenario Lab Every Payment Firm Needs

Payment firms and fintechs in the Kingdom have widely adopted Nafath for customer authentication, meeting the Saudi Central Bank's requirements for strong customer authentication and eKYC. But as PCI DSS v4.0 becomes the standard for cardholder data environment security, fraud and compliance managers face a new question: does Nafath device binding PCI DSS 8.4.2 payment fraud control testing prove that the device initiating a payment transaction is truly bound to the authenticated identity?

PCI DSS v4.0 Requirement 8.4.2, issued by the Payment Card Industry Security Standards Council, mandates multi-factor authentication for all access into the cardholder data environment. For payment applications, this means proving not only that the user authenticated successfully through Nafath, but that the device presenting the payment request is the same device that was bound to that user's identity during onboarding. Nafath provides strong identity proofing and authentication, but it does not, on its own, enforce device binding or transaction signing. A user can authenticate via Nafath on one device and then submit a payment from another—or an attacker can replay a valid Nafath session token from a compromised device.

This gap is precisely what Qualified Security Assessors examine during PCI DSS assessments. They expect to see evidence that your payment application enforces device trust at the point of transaction, not just at login. This article walks through four test scenarios that expose weaknesses in device binding and transaction signing, and explains the evidence QSAs expect in your fraud-control review.

Why Nafath Authentication Alone Is Not Sufficient for PCI DSS 8.4.2

Nafath is a federated identity service. When a user authenticates, Nafath returns a token that confirms the user's identity. Your payment application consumes that token and grants access. This satisfies the "something you have" factor—the user's mobile device registered with Nafath—and the "something you know" factor—the user's PIN or biometric.

But PCI DSS 8.4.2 requires that multi-factor authentication be applied to access into the cardholder environment, which in a payment application includes the moment a user initiates a payment transaction. If your application does not independently verify that the device submitting the payment is the same device that was bound during onboarding, you have a control gap. An attacker who obtains a valid Nafath token—through session hijacking, SIM swap, or malware—can present that token from any device and initiate fraudulent payments.

Device binding means cryptographically linking a specific device to a user's account, typically by generating a key pair on the device during onboarding and storing the public key on your server. Transaction signing means requiring the device to sign each payment request with its private key, proving that the request originated from the bound device. Together, these controls satisfy PCI DSS 8.4.2 by ensuring that the authentication factors are present at the point of transaction, not just at login.

The Four Test Scenarios QSAs Expect to See

A robust fraud-control review includes scenario-based testing that simulates real-world attack vectors. QSAs look for evidence that you have tested your device-binding and transaction-signing controls against common fraud scenarios and documented the results. The following four scenarios are standard in payment fraud control assessments.

Scenario One: SIM Swap Attack

In a SIM swap attack, an attacker convinces a mobile operator to transfer the victim's phone number to a SIM card in the attacker's possession. The attacker can then receive SMS one-time passwords and, in some cases, re-register the victim's Nafath account on a new device.

Test objective: Determine whether your payment application allows a user to authenticate via Nafath on a new device after a SIM swap, and whether it permits payment transactions from that new device without re-binding.

Test steps:

1. Register a test user and bind a device during onboarding.
2. Simulate a SIM swap by transferring the test user's phone number to a different SIM card and device.
3. Authenticate the test user via Nafath on the new device.
4. Attempt to initiate a payment transaction from the new device.

Expected outcome: The payment application should detect that the device has changed and require re-binding or step-up authentication before allowing the transaction. If the application permits the transaction using only the Nafath token, device binding is not enforced.

Scenario Two: Cloned Session Token

Session tokens can be extracted from a compromised device or intercepted through malware. An attacker who obtains a valid Nafath session token can replay it from a different device.

Test objective: Determine whether your payment application validates that the device presenting the session token is the same device that was bound during onboarding.

Test steps:

1. Authenticate a test user via Nafath on a bound device and capture the session token.
2. Transfer the session token to a second, unbound device.
3. Present the session token from the second device and attempt to initiate a payment transaction.

Expected outcome: The payment application should reject the transaction because the device presenting the token does not match the bound device. If the transaction is permitted, the application is not enforcing device binding at the transaction layer.

Scenario Three: Jailbroken or Rooted Device

Jailbroken iOS devices and rooted Android devices allow attackers to bypass operating-system security controls, extract cryptographic keys, and manipulate application behaviour. Payment applications should detect these conditions and either refuse to run or apply additional fraud controls.

Test objective: Determine whether your payment application detects jailbroken or rooted devices and enforces appropriate controls.

Test steps:

1. Jailbreak an iOS device or root an Android device.
2. Install the payment application and attempt to bind the device during onboarding.
3. Authenticate via Nafath and attempt to initiate a payment transaction.

Expected outcome: The payment application should detect the jailbroken or rooted state and either refuse to bind the device, refuse to execute the transaction, or apply step-up authentication. If the application permits normal operation, it is vulnerable to key extraction and transaction manipulation.

Scenario Four: Man-in-the-Middle Interception

In a man-in-the-middle attack, an attacker intercepts communication between the payment application and your server, capturing authentication tokens and payment requests. Even with TLS encryption, misconfigurations such as disabled certificate pinning can allow interception.

Test objective: Determine whether your payment application enforces certificate pinning and detects man-in-the-middle interception.

Test steps:

1. Configure a proxy tool to intercept HTTPS traffic between the payment application and your server.
2. Authenticate a test user via Nafath through the proxy.
3. Capture the Nafath token and payment request.
4. Replay the captured request from a different device or modify the payment amount.

Expected outcome: The payment application should detect the interception through certificate pinning and refuse to communicate. If the application permits the connection, or if the replayed request is accepted, both transport security and device binding are inadequate.

Evidence QSAs Expect in Your Fraud-Control Review

When a QSA reviews your PCI DSS 8.4.2 controls, they will ask for documentation of your fraud-control testing. This includes:

• Test plan and scenarios: A written description of each test scenario, the controls being tested, and the expected outcomes.

• Test results: Screenshots, logs, or reports showing the application's response to each scenario. If a scenario revealed a control gap, document the remediation and re-test results.

• Device-binding architecture: A technical description of how device binding is implemented, including key generation, storage, and validation at the transaction layer.

• Transaction-signing implementation: Evidence that each payment request is signed by the bound device and validated by your server before processing.

• Fraud-monitoring integration: Logs showing that device-binding failures, jailbreak detections, and other anomalies are captured by your fraud-monitoring system and trigger alerts or step-up authentication.

QSAs will also review your fraud policies and incident-response procedures to confirm that device-binding failures are treated as fraud indicators and escalated appropriately.

Integrating Device Binding into Your Broader Fraud-Control Program

Device binding and transaction signing are not standalone controls. They are most effective when integrated into a comprehensive fraud-control program that includes:

• Customer journey threat modeling: Mapping each step of the customer journey—from onboarding through payment—and identifying fraud scenarios at each step.

• Fraud scenario testing: Regularly testing controls against real-world attack vectors, not just during the initial implementation.

• Customer notifications: Alerting customers immediately when a new device is bound, a payment is initiated, or a device-binding failure occurs.

• Social-engineering and mule-account controls: Detecting and blocking accounts used for money laundering or fraud, even when device binding is intact.

The Saudi Central Bank's Counter-Fraud Framework, issued by SAMA, requires institutions to implement fraud-detection and prevention controls across all customer-facing channels. PCI DSS 8.4.2 is a complementary requirement focused specifically on the cardholder environment. Together, they form the regulatory foundation for payment fraud controls in the Kingdom.

How We Help Payment Firms Test and Remediate Device-Binding Gaps

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 engagement follows a structured process: we map customer journeys and their controls, threat-model fraud scenarios for each step, test control effectiveness through scenario walkthroughs, and recommend a prioritized roadmap with experience impact. Deliverables include a journey-by-journey control assessment, fraud scenario test results, and a remediation roadmap. The assessment typically requires four to eight weeks.

With your approval we test in a pre-production environment; live testing is limited to agreed, safe scenarios. The review focuses on fraud controls and does not include penetration testing, though it pairs well with our penetration testing service. The engagement is designed to meet the requirements of SAMA's Counter-Fraud Framework, SAMA's Cybersecurity Framework, and PCI DSS.

If you are preparing for a PCI DSS assessment or a SAMA fraud-control review, the four-scenario lab described in this article is a practical starting point. It exposes the most common device-binding gaps and provides the evidence QSAs and regulators expect to see.