Testing Nafath Device Binding Before a SIM-Swap Attack

Nafath device binding fraud prevention depends on more than having the control switched on. Most Saudi banks and fintechs now rely on Nafath to bind a customer to a device, and the SAMA Cyber Security Framework (SAMA CSF) expects strong multi-factor authentication around customer access. What auditors and examiners increasingly ask is simple: how do you know the binding holds when someone takes over a phone number? This article gives Digital Banking Security Managers and Fraud Prevention Teams a practical way to answer that question through four test scenarios, the behaviour you should expect, and an evidence log.

Why device binding needs scenario testing

Device binding links an authenticated customer to a specific device so that a stolen password or intercepted one-time code is not enough to take over an account. Its weakness is the recovery and re-enrolment path. If an attacker can take over a phone number through a SIM swap and then reach a re-registration flow, the binding can be replaced rather than defeated.

Configuration reviews rarely catch this. The control exists, but nobody has walked through what happens when the phone number, the device and the Nafath identity change in different combinations. Scenario testing closes that gap.

Before you start

Agree the test conditions first.

• Use a pre-production environment with test customers, or agree a limited set of safe scenarios for live testing with the business owner.
• Prepare test accounts at different risk levels, for example a basic retail account and one with high transfer limits.
• Confirm what you can simulate. A real SIM swap is not needed; you can emulate its effect by moving the registered number to a new test handset.
• Name an observer from fraud operations and one from security so that alerts, case creation and customer notifications are checked as well as the app behaviour.

Scenario 1: SIM swap with the same device

The attacker controls the phone number, but the customer's bound device is unchanged or still in the customer's hands.

Test: Move the number to a new SIM, then attempt login, a one-time-code request and a high-value payment from the original bound device and from any other channel that relies on SMS.

Expected behaviour:

• SMS codes alone do not authorise sensitive actions.
• The bound device continues to work, but the number change raises a risk signal.
• A step-up check or a hold applies to high-risk transactions soon after the change.
• The customer receives a notification through a channel the attacker does not control.

Scenario 2: SIM swap with a new device

The attacker holds the number and a new handset, and tries to enrol it.

Test: From an unbound device, start login and enrolment using only the phone number and received SMS codes.

Expected behaviour:

• The new device cannot become trusted on the strength of SMS alone.
• Enrolment requires Nafath authentication that the attacker cannot complete.
• Failed attempts are logged and rate-limited, and a fraud alert is created.
• Limits on new devices apply, with a cooling-off period for high-value or new-payee transfers.

Scenario 3: Nafath re-registration

The customer, or someone impersonating them, re-registers in Nafath or re-binds the app after a change of device or credentials.

Test: Complete re-registration with a valid Nafath identity, then check what the bank does with the old binding. Repeat with a recently changed number and with repeated re-registrations in a short window.

Expected behaviour:

• The previous device binding is revoked or explicitly reviewed, not silently kept alongside the new one.
• The customer is notified of the change on all known channels.
• Repeated re-registrations trigger review.
• Transaction limits for the new binding reflect the risk of a recent change.
• Support staff cannot bypass the binding process without a documented, authorised procedure.

Scenario 4: Simultaneous session attempts

Two devices try to use the same account at the same time, one legitimate and one hostile.

Test: Log in on the bound device, then attempt login and transaction initiation from a second device and location. Reverse the order and repeat.

Expected behaviour:

• Session policy is clear and enforced: either the earlier session is ended or the second is blocked.
• Transaction signing is tied to the bound device, not merely to the session.
• Conflicting sessions create an alert and appear in fraud monitoring.
• Session tokens cannot be reused across devices.

The evidence log format

Internal audit and SAMA examiners want to see that testing was planned, performed and followed up. A simple log works well. For each test record:

1. Test ID and scenario name.
2. Control objective and the SAMA CSF requirement it supports.
3. Date, environment, tester and observer.
4. Preconditions, including account type and device state.
5. Steps performed.
6. Expected result.
7. Actual result, with screenshots or system log references.
8. Alerts, cases and customer notifications generated.
9. Pass, fail or partial, with severity.
10. Remediation owner, due date and retest date.

Keep the log under version control and retain the underlying screenshots and logs. A failed test with a tracked fix and a retest is stronger evidence than a clean result with no detail.

Common findings

• SMS remains a fallback for sensitive actions.
• Old bindings persist after re-registration.
• Notifications go only to the number that was just taken over.
• Support-desk overrides are undocumented.
• Fraud monitoring does not receive device and number change events.

Signs it is time for an independent review

An independent review is worth considering when your Nafath integration has changed recently, when device-binding logic was built by several teams, when SIM-swap cases have appeared in your fraud data, or when an audit or SAMA examination is approaching and the test evidence is thin.

A good outcome is a documented set of scenario results, a clear view of which journeys are exposed, and a prioritised fix list that accounts for customer experience.

How CISO Consulting 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. We run it in four steps: map customer journeys and their controls, threat-model fraud scenarios for each step, test controls through scenario walkthroughs, and recommend a prioritised roadmap with experience impact. The assessment takes 4–8 weeks and delivers a journey-by-journey control assessment, fraud scenario test results and a remediation roadmap. 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 rather than penetration testing.

If you would like the four scenarios above tested and evidenced, we are glad to discuss scope.