Ras Al Khaimah · Riyadh · Karachi soon 10:00 – 18:00 AST  ·  contact@coalescence.me

E-Government

Integrating with Nafath and Absher: a guide for Saudi digital services

Saudi Arabia operates national identity and citizen transaction platforms at very large scale. For a new public service, the design question is how early to integrate with them.

19 August 20267 min readE-Government

Absher processed more than 240 million electronic transactions during the first half of 2026 across its individual and business platforms. Nafath has completed billions of verification operations since launch, and the Ministry of Interior has issued 28 million digital identities. For organisations delivering citizen services in the Kingdom, this infrastructure represents both an authentication mechanism and an established distribution channel.

Integrate at design stage

A common and costly sequence is to build proprietary registration, credential storage and identity verification, then add Nafath as an alternative sign-in method shortly before release. The result is two identity models that disagree on user identity, and a continuing support burden arising from accounts that exist in one model but not the other.

Identity determines the structure of the user record, the authorisation model, the audit trail and session policy. Establishing Nafath as the identity source at design stage allows these to be defined once and consistently.

Design consequence

Where national identity is the source of truth, the service stores no credentials. This removes a category of breach exposure, a category of support volume, and a measurable portion of the compliance surface.

Provide for citizens who cannot authenticate

National identity adoption is high but not universal. A proportion of users cannot complete the flow: new residents, expired documents, lost devices, and businesses acting through an authorised representative. A service that functions only for authenticated users is incomplete.

Each programme we deliver includes a defined secondary path, whether assisted service at a counter, a delegated representative model, or a verified manual route with a recorded approval step. These are specified alongside the primary journey and tested with the same rigour.

Aligning with Digital Government Authority standards

The Digital Government Authority's maturity indices have made service quality measurable and comparable between entities. Absher ranked first in the 2026 Digital Experience Maturity Index with a score of 94.38 per cent. The indices consistently reward completion rate, absence of unnecessary steps, transparency of application status, and parity between Arabic and English.

In design terms this translates into a small number of measurable questions. How many steps separate intent from completion? Can an applicant determine the status of their application without contacting the entity? Does the Arabic interface meet the same standard as the English one?

Interoperability determines effort

A permit application requiring supporting documents from two other authorities is an orchestration problem. The majority of engineering effort concentrates in the inter-agency exchanges: agreeing the interface contract, handling planned and unplanned unavailability at the other authority, and defining what the applicant sees while a dependency remains outstanding.

We model these as long-running workflows with observable state rather than synchronous calls. An applicant should receive an accurate status and expected timeframe when an upstream authority is unavailable.

Services that score well on the maturity indices are characterised by deliberate handling of exception paths rather than breadth of features.

Regional portability

The same service architecture transfers across the GCC with different identity providers. UAE Pass serves more than 12.5 million users across 15,000 services from over 350 entities, and has been recognised by the World Economic Forum as a model for integrated government digital infrastructure. Qatar, Bahrain, Oman and Kuwait operate comparable platforms at varying stages of maturity.

For services intended for more than one GCC market, isolating the identity provider behind an internal interface from the outset is the decision that determines the cost of the second deployment. Across nine programmes, this has consistently been the factor separating a straightforward regional rollout from a second full implementation.

Related enquiries

Architecture and compliance questions arising from this article are answered directly by the engineering team.