Identity Verification for Apps in Saudi Arabia: When You Need Nafath and What Else Works

If you are building an app or a platform for users in Saudi Arabia, your first decision belongs to the user journey rather than the stack. Work out which single step genuinely requires knowing that the person is who they claim to be, and only then pick the tool that proves it. Plenty of products get the order wrong: they demand full government verification from a visitor who has not tried the service yet, then let a contract get signed or money get withdrawn with no check at all.

What follows is what Saudi authorities actually publish about the National Single Sign-On (Nafath) and about getting connected to it, what they do not publish, and the alternatives you can sign up for yourself today. Every figure and condition here comes from an official source consulted on 21 September 2026.

Start with the step that earns a check

Financial regulation gives you a usable yardstick even if you are nowhere near a bank. The Saudi Central Bank's rules on opening bank accounts remotely for individuals, updated by circular 472021863 dated 25/09/2025, make the bank responsible for establishing who the customer is, and require that it do so from what the rule calls a "reliable and independent source." The principle travels well beyond banking: the more a third party stands to lose when somebody impersonates someone else, the more you need an independent source instead of what the user typed about themselves.

Here is that principle applied to less regulated products:

Three of those rows put verification long after registration. Moving each check to its natural moment keeps the front door open and cuts the number of verifications you pay for.

Two services, one name

Nafath is usually discussed as though it were a login button. In SDAIA's service catalogue it is two separate services, each with its own record and launch date:

(Source: the two service records in the SDAIA service catalogue, consulted 21 September 2026.)

The split is the part that changes your design. The first answers "who is signing in right now?" The second answers "is this person present and agreeing to this specific transaction?" A product that needs the second at contract time may not need the first at sign-up at all.

The operator is the same either way. Nafath is described on its own platform as an initiative of the National Information Center, and the site footer states that it is developed and operated by the Saudi Data and Artificial Intelligence Authority (SDAIA). SDAIA's page for the centre adds that the centre reports to the authority, owns and operates the Government Secure Network, and hosts the Government Service Bus.

What SDAIA publishes about applying, and what it does not

Both service records name their target audience plainly: individuals, businesses, government entities, commercial establishments, charities, and micro and small enterprises. The door is not government-only.

Under required documents, SDAIA publishes four conditions for an entity that wants to connect:

1. Submit the request through SDAIA's official channels.
2. Complete the forms SDAIA provides in order to finish the request.
3. Sign the agreement and every document the authority asks for.
4. The end user only needs an activated Absher account.

The fourth condition is the good news: your users do not have to enrol in anything new. The first three mean that connecting is a signed agreement with a government body, not a key you mint yourself in a dashboard.

The official channels listed on Nafath's help and support page are the call centre on 8001221111, the address Support@nic.gov.sa, and @NIC_Care on X. The same page states a 15-working-day handling window, but describes it as the window for reports, enquiries and complaints, not as an approval time for an integration request.

Now the honest part, because confusing what is published with what is guessed will cost you real planning time:

• No public technical documentation. There is no published developer guide for Nafath, no announced sandbox, and no official description of the protocol or the fields it returns. The flows and endpoint names you will find on agency blogs are not traceable to any document. Treat them as assumptions until the operator hands you the specification after you sign.
• No published eligibility rules. The record names no particular activity, no minimum company size, and no requirement for a Saudi commercial registration.
• No published cost to the connecting entity. The word "free" on the record refers to the end user. Do not budget on the assumption that integration is free for you; carry it as an open line until the agreement arrives, alongside the other moving parts in our breakdown of what a mobile app costs in Saudi Arabia.
• No published definition of the assurance levels. The case study the operator submitted to the OECD Observatory of Public Sector Innovation states that the app has three authentication levels, and that the National Cybersecurity Authority classified service sensitivity to determine the appropriate level for each service. What each level means is not published, so do not design screens around a level you assume you will get.

The same case study names a limit that matters to anyone building business-to-business software. Authenticating legal identities is listed among the open challenges, and the submission is blunt about the consequence:

Without proper governance of legal identities, digital identity services for legal entities will not be possible.

In practice: Nafath tells you who the person is. It does not tell you that they may act for a company. Authority to represent needs a different source.

What the user goes through, and where it breaks

The official Nafath user guide documents the flow and its error states together, and those error states are what your screens have to handle:

• The user enters their national ID or iqama number on your side, a request number appears on your screen, and a notification reaches their Nafath app.
• They open the app and see several numbers, and must pick the one matching what is on your screen. Picking the wrong number ends the attempt, and they are told to go back to you and start a new request.
• The window is 60 seconds from the moment the request is submitted. Miss it and they need a fresh request from you.
• Then a six-digit personal code created when they first activated the app, or a biometric capture depending on the request type.
• The alternative route inside Nafath: ID number plus the Absher account password, followed by a code sent to the mobile registered in Absher.

Three things follow immediately. The request number belongs on your screen large and unmistakable, because the user is comparing it against other numbers under time pressure. The waiting screen needs a visible countdown and a "send a new request" button rather than a spinner that never resolves. And every verification step needs an exit: what happens to the person whose app crashes, whose connection drops, or whose face capture will not complete? The operator publishes no success rate, so do not assume this step always works, and keep a human or deferred path.

Two features in the Nafath app listing, published by the National Information Center, deserve the attention of whoever designs your onboarding. The first is one-time authentication, which lets a person authenticate in order to complete a biometric verification request without already holding a registered digital identity account, so a missing account is not automatically a wall in front of a new user. The second is the temporary suspension of the digital identity, a state the user can switch on themselves, and one your error messages should distinguish from a technical failure.

Alternatives that work while you wait

If direct integration is out of reach for now, or your schedule cannot absorb the wait for an agreement, these are official routes with published sources:

Wathq, for verifying companies and documents. The Wathq developer portal is self-service: create an account and confirm it by email, choose a package, create an application and select the services you want, then take your API key and start querying, with a test environment available for some services. Published services cover commercial registration data and company articles from the Ministry of Commerce, notarised powers of attorney and property deeds from the Ministry of Justice, the national address from Saudi Post, employee data from the General Organization for Social Insurance, and foreign investor entity data from the Ministry of Investment. This is the practical answer to the question Nafath does not answer: is this person authorised to act for this company?

Yakeen from Elm, for verifying individuals' data. The product sheet lists verification of people's, vehicles' and dependants' data, packages for online lookups, batch runs and IPO subscriptions, and a Rowad package aimed at entrepreneurs and startups. Yakeen is also recognised in regulation, not just in marketing: SAMA's rulebook allows a bank to use it as an additional option for verifying customer identity electronically, on the conditions that customer approval is obtained in advance and that the customer pays no extra fee. Take that as a general design rule: consent before the lookup, in wording that appears on your screen.

The Tawakkalna partners portal, if reach is the goal. The Integrated Services record in SDAIA's catalogue describes it as free and open to companies, institutions and the private sector, and publishes the path: developer portal, build the service, trial and approval, review, launch. Registration requires the entity's details, an account manager, an authorisation letter for that manager, and acceptance of the terms.

Mobile plus one-time code, with verification deferred. This remains a respectable choice for most products, as long as you do not call it identity verification. It proves control of a number, nothing more. Pair it with a stronger check at the step that deserves one.

If your product is financial or otherwise supervised, note one binding rule: SAMA requires financial institutions to accept the Absher platform's electronic identity for customers they already have, in any transaction where no copy of the ID needs to be taken. Refusing the digital ID and demanding a photocopy is not a neutral choice there.

What to store afterwards, and what not to

A successful check does not entitle you to keep everything that passed through it. Article 19 of the Implementing Regulation of the Personal Data Protection Law obliges the controller to collect the minimum personal data necessary for the purpose of processing, and to retain the minimum necessary.

Translated into decisions about your schema: store the verification result, its timestamp and an internal reference for the transaction. Not face images or fingerprints, which never reach you anyway, because capture and matching happen inside the Nafath app. And if the ID number itself is not needed to run the service or to meet an obligation on you, do not keep it merely because it passed in front of you.

Verification is one link in a longer chain of obligations that also covers consent, disclosure, the data subject's rights and what you do after a breach, which we work through in our guide to customer data protection and compliance.

Before you write a line of code

• Name the one step where real harm occurs, and put verification there rather than at the front door.
• Separate "who are you" from "do you approve this transaction"; they are different services.
• Design the failure states first: expired window, wrong number, dropped connection, suspended identity.
• If you sell to businesses, plan for two sources: the individual on one side, their authority to act for the company on the other.
• Apply through the official channels early, and ship a first version on an alternative, because agreements do not follow your release plan.
• Write the retention policy before the first verification, not after the first audit.

At Snaabble we build apps and platforms for clients in Egypt and the Gulf, and in projects like these the hard question is usually the order of the journey rather than the choice of tool. If you are planning an app or a platform for the Saudi market, send your idea to the Snaabble team and you will get an initial plan with a time and cost estimate within 24 hours, free and with no obligation.

Sources

• National Single Sign-On — about and help and support
• SDAIA service catalogue: access to government and private services, biometric verification, Tawakkalna Integrated Services
• Nafath platform user guide (PDF)
• National Information Center — SDAIA
• Implementing Regulation of the Personal Data Protection Law (PDF)
• SAMA Rulebook: opening bank accounts remotely for individuals, acceptance of the digital ID on Absher and Tawakkalna, Yaqeen for ID verification
• Wathq developer portal and service list
• Yakeen — Elm (PDF)
• Nafath app case study — OECD OPSI
• Nafath on the App Store