Nafath
Nafath is the national single sign-on for Saudi digital services. Where a service needs to know it is genuinely dealing with a particular person, this is how that is established.
Nafath is the national single sign-on for Saudi digital services. Where a service needs to know it is genuinely dealing with a particular person, this is how that is established.
What Nafath holds, and why that matters here
Nafath provides verified national identity for digital services in the Kingdom. For any service dealing with citizens or residents on matters that require certainty about who someone is, it is the authoritative mechanism.
For an assistant, the significance is the same as any identity connection but with higher assurance. A Nafath-verified session establishes identity to a standard that supports disclosing genuinely sensitive information and taking genuinely consequential actions.
- Verified identity — confirmation of who the person is, to a national standard.
- Authentication events — the confirmation that a sign-in genuinely occurred.
- Session state — whether the verified session is still valid.
- Consent for the interaction — captured where the service requires it.
- Attributes the service is entitled to — scoped to what the service needs.
Questions Nafath verification lets Elbi answer
Is this genuinely the account holder?
Verified identity to a national standard rather than knowledge-based questions.
May we disclose this?
Entitlement determined by verified identity rather than by claims made in conversation.
Is the session still valid?
Session state, so a stale session cannot be used.
Can they act on this?
Whether a consequential action is permitted for this verified person.
Which services apply to them?
Attributes the service is entitled to receive.
Has verification expired?
Re-verification where an action requires fresh assurance.
How Elbi uses Nafath verification
- The conversation reaches something personalGeneral questions need no identity. When a conversation turns to something about this person — their application, their account, their case — Elbi explains that it needs Nafath verification before it can answer, and why.
- A Nafath request is raisedThe request goes through the organisation's Nafath integration and is tied to the person's national ID or iqama number. It appears in the person's Nafath app, not in the chat window.
- Confirmation happens in the Nafath appNafath asks the person to confirm in its app, typically by choosing the number shown on the service's screen, along with any further check the app itself requires. None of that passes through the conversation.
- Elbi receives the result, not the processWhat comes back is confirmation that verification succeeded and the attributes the integration is entitled to receive. Elbi never asks for passwords or one-time codes in chat, under any wording.
- Disclosure stays inside agreed limitsVerification opens a defined set of answers, the ones listed before launch, not everything held about the person. It is also time-limited: a consequential step can require fresh verification even within the same conversation.
- Changes to the record use the official channelUpdating personal details, or anything with legal effect, is routed by default to the channel your organisation already uses for it. Any exception is a deliberate decision made for one well-defined action.
Scope and control around Nafath
| Direction of access | Verification flows one way. The national service confirms who the person is; Elbi uses that confirmation and writes nothing back to Nafath. |
|---|---|
| Who can see what | Only the verified person, and only the answers you allowed for a verified session. A relative or colleague asking on someone's behalf is not verified as that person, whatever they say. |
| Credentials | The credentials Elbi uses to reach the Nafath integration are issued by you, and you can rotate or revoke them at any time without involving us. |
| Where data goes | The verification result and its attributes serve the conversation in which they were given, and do not outlast it for long: message content is destroyed within 24 hours, usually at the end of the conversation, and no external AI service ever sees it. |
| Audit | Each disclosure can be tied to the verification that preceded it — which identity was verified, when, and which category of answer it unlocked — the record a complaint or review will ask for. |
| If Nafath is unavailable | Elbi says verification is not possible at the moment, carries on with general answers and points to your other official channels. It never falls back to security questions. |
What this replaces
For citizen-facing services the assurance level is what matters. A great deal of public and financial contact involves information that should only ever reach the individual concerned, and establishing that through conversation is not adequate for the purpose.
With verified identity, an assistant can move from explaining processes generally to answering about a specific person's specific case — which is where most of the value in public-service contact actually sits.
It also creates a defensible audit position. Disclosure tied to a verified authentication event is something an organisation can evidence afterwards, which matters when a complaint or a review arrives months later.
Where Nafath verification is expected
Government services
Case and application status for a verified citizen.
Banking
High-assurance identity for account-specific interaction.
Healthcare
Patient-specific information where certainty is required.
Telecom
Actions with authentication consequences.
Where Nafath verification pays off first
The first candidate is the status question that today cannot be answered in chat at all: where is my application, has my request been approved, what is still outstanding on my file. In government and financial services these questions are routine, and without verified identity the only honest reply is "please call" or "please log in".
The second is keeping verification proportionate. Nafath should be requested at the point a conversation turns personal, not at the start. Someone asking about opening hours or required documents should never be asked to verify; someone asking about their own case should be asked once, clearly, with a sentence explaining why.
The third is the handover. When a verified conversation needs a person, the fact of verification and the case it concerns should travel with it, so the customer is not asked to prove who they are a second time to the agent who picks it up.
What connecting Nafath involves
- Establish the Nafath integrationNafath access is granted by the service operator under its own onboarding requirements. Establishing which integration the deployment will use, and for which services, comes before anything else.
- List what verification unlocksWrite down which answers become available after verification and which are never given in chat. The list is reviewed before launch, and it is what the assistant is held to.
- Decide how people are matched to recordsHow a verified identity is matched to your own records — usually by national ID or iqama number — and what happens when no record, or more than one, is found.
- Set how long verification lastsHow long a verification stays valid within a conversation, and which steps need a fresh one regardless.
- Plan for people Nafath does not coverVisitors, people who are not registered and anyone unable to use the app need a clear alternative route that your organisation defines, such as a branch, a call centre or your own portal.
- Test the unhappy pathsA request that is declined, one that expires unconfirmed, a person who verifies but has no record with you, and someone asking on another person's behalf. Each should end with a plain explanation and a next step.
Nafath, national ID numbers and the PDPL
Verification itself tells you something personal: that a named individual, identified by national ID or iqama number, contacted you at a particular time about a particular matter. Under the Personal Data Protection Law, that record and the attributes returned with it are personal data, processed so that the person can be answered safely.
The ID number deserves particular care. It is the key that links a conversation to everything else held about the person, so it should be used for matching and not repeated back in answers, shown to agents who do not need it, or copied anywhere it was not meant to go.
Notice matters as well. People should be told, before they verify, what verification will allow the assistant to see and say. Nafath users confirm requests from many services; one short sentence explaining this one keeps the step informed rather than habitual.
What organisations typically see
How identity is usually checked in chat, and how Nafath compares
The most common alternative is a one-time code sent by SMS to the number on file. It is familiar and quick, but it proves possession of a phone number rather than identity, and it relies on the number on file being current.
Knowledge-based checks — date of birth, account number, the last transaction — are the other habit. They are easy to deploy and weak in practice: the answers are often known to relatives or exposed elsewhere, and they teach people to type personal details into chat windows, a habit fraudsters depend on.
Many organisations avoid the question entirely and send people to log in to a portal or app instead. That is safe, and it moves the conversation somewhere else. Nafath lets the answer stay in the conversation, verified through the same app people already use for government and banking services.
Common questions
No. It matters where the assistant discloses personal information or takes consequential action. Informational contact needs no identity at all.
It receives confirmation of a verified identity and the attributes the service is entitled to — not document images.
The assistant handles the informational half of the conversation and routes anything personal to a person.
No. Confirmation happens only in the Nafath app. A chat message asking for a password or one-time code should be treated as suspicious, whoever appears to send it.
Access is granted by the service operator under its own onboarding requirements. Which integration a deployment uses, and for which services, is settled at the start rather than assumed.
No. Verification identifies the person who confirmed in the app, and answers are limited to that person. Requests on someone else's behalf go to your usual channel for authorised representatives.
Let verified customers get their own answers
Nafath-verified conversations in Arabic and English, within the limits you agree before launch.