Saudi B2B teams routinely over-specify their signing requirements. The instinct is reasonable — Nafath is sovereign, biometric, and trusted; a Qualified Electronic Signature (QES) backed by it is the highest cryptographic tier under the Saudi Electronic Transactions Law. So surely you'd want it on every contract, always. The legal text says something more nuanced. Saudi ETL grants electronic signatures the same evidentiary weight as handwritten signatures the moment a set of technical conditions is met — and the Advanced Electronic Signature (AES) tier meets those conditions for the document types that make up roughly 95% of Saudi B2B signing volume. Defaulting every signature to QES with Nafath buys you legal overkill at the price of coverage gaps and signing friction that drops completion by double digits.
active Nafath users — essentially every Saudi national and Iqama holder. Outside that population (foreign signers, non-resident counterparties, expat consultants), Nafath is unavailable and QES through it is impossible
National Information Center / Absher coverage, 2025
of Saudi B2B contracts include at least one non-Saudi counterparty (foreign vendor, regional partner, expat employee at hire) — exactly the cohort that cannot complete a Nafath-backed signature flow
SahlSign Saudi customer document-mix analysis, 2026 (n=84 organisations)
of Saudi ETL specifies the technical conditions an electronic signature must meet to carry the same legal weight as wet ink. The AES tier satisfies them. The statute does not require QES for commercial agreements as a class
Saudi Electronic Transactions Law, Royal Decree M/18 of 1428H
What Saudi ETL actually says about signature tiers
Saudi Arabia recognised electronic signing in 2007 via Royal Decree No. M/18 of 1428H, the Electronic Transactions Law (ETL), supplemented by its Implementing Regulations. Like eIDAS in Europe, the framework recognises three tiers: a basic electronic signature, an advanced electronic signature, and a certified/qualified electronic signature anchored on a Saudi-licensed certificate authority. The Communications, Space and Technology Commission (CST, formerly CITC) regulates the licensed CAs that issue qualified certificates; Nafath, operated by the National Information Center, provides the citizen-side identity assertion that powers QES flows in practice.
Most of the operational confusion sits in one place: the assumption that QES is required for legally binding signing. It isn't. Article 5 of the ETL lays out the conditions an electronic signature must satisfy to carry the same evidentiary weight as a handwritten one — unique linkage to the signatory, sole control of the signing data, and tamper-evident binding to the document. Any properly built AES implementation satisfies those conditions. QES adds a state-anchored identity certificate on top, which the statute requires only for specifically listed document categories.
Saudi ETL signature tier required by document type. AES is sufficient for the vast majority of commercial signing; QES is mandated only for a narrow set of state-facing transactions.
| Jurisdiction | Law | Cross-border transfer rule | Intensity |
|---|---|---|---|
| Employment contracts | Saudi Labour Law (Royal Decree M/51) | AES sufficient. No QES requirement for employment agreements; the ETL applies and AES meets Article 5 conditions. | Moderate |
| NDAs / confidentiality agreements | Commercial law / general contract | AES sufficient. Often SES (link + OTP) is enough — but AES gives a defensible audit trail for low marginal cost. | Moderate |
| Vendor / service agreements | Commercial Court Law (M/93) | AES sufficient. Saudi commercial courts have accepted AES-signed contracts as evidence since the ETL came into force in 2007. | Moderate |
| Sales contracts (non-real-estate) | Commercial law | AES sufficient. Same evidentiary status as wet ink for commercial transactions. | Moderate |
| Lease agreements (Ejar) | Real Estate Authority (REGA) regulations | AES sufficient. Ejar platform accepts electronically signed leases for registration; QES not required. | Moderate |
| Real estate transfer of title | Ministry of Justice — notarisation | QES required. Transfer of registered ownership requires a notarised act through MoJ channels, anchored on a qualified certificate. | Strict |
| Court filings (Najiz portal) | Bureau of Experts — judicial e-filing rules | QES required. Litigants and counsel filing through Najiz authenticate via Nafath; pleadings carry a QES. | Strict |
| Government tendering (Etimad) | Government Tenders and Procurement Law | QES required. Bidders submitting through Etimad must hold a qualified certificate; vendor authentication is via Nafath. | Strict |
| Power of attorney for state acts | Notarial law | QES required. POAs that empower a representative to act before government bodies must be notarised electronically with a qualified signature. | Strict |
The Nafath friction problem
Nafath is excellent identity infrastructure. It's also designed for transactions where the signer has already chosen to interact with a Saudi government service — applying for a visa, paying a fine, registering a vehicle. The user is motivated; the friction is acceptable. Commercial signing has a different motivation curve. The signer is a counterparty you're trying to convert from "considering" to "signed" as quickly as possible. Every additional authentication step costs completion rate.
Signature completion rate by signing method
Share of sent signing invitations that result in a completed signature within 48 hours. Higher is better.
SahlSign aggregated Saudi customer telemetry, 2026 (n=14,200 sent invitations across 84 organisations). Wet-ink baseline from comparable Forrester paper-cycle studies.
QES with Nafath beats paper, but it loses double digits to AES on completion. Two reasons. First, every Nafath signature requires the signer to install the Nafath app (if they haven't already), open it, accept a push notification, and complete biometric authentication. Each of those steps shaves a few percentage points off completion. Second — and this is the killer — Nafath is unavailable to anyone who isn't a Saudi national or Iqama holder. If your counterparty is a foreign consultant, a regional VP visiting from Dubai, an offshore vendor, or a candidate you haven't yet hired (and therefore haven't yet sponsored for an Iqama), the QES flow is structurally impossible. You bifurcate the workflow: QES for Saudi signers, AES for everyone else, every contract handled twice.
When you genuinely need QES
QES isn't wrong — it's a precision tool. There is a clear list of document types where it is either legally mandated or operationally required by the receiving authority. The rule is: default to AES, escalate to QES when this list applies.
Use QES with Nafath when (and only when) the receiving authority demands it
- Filing with a Saudi court via the Najiz portal
Pleadings, motions, judgment requests, and appeals filed through the Ministry of Justice's Najiz e-filing platform authenticate counsel via Nafath and carry a QES on every submitted document.
- Real estate transfer of title
Registration of ownership transfer at the MoJ Notary requires a qualified electronic signature; AES is insufficient because the registration itself is a notarial act.
- Government tendering through Etimad
Bidding documents, contractual submissions, and post-award contract execution on the Etimad procurement platform require vendor authentication via Nafath and a QES on submission.
- Notarised powers of attorney
POAs that authorise a representative to act before government authorities (commercial registration, tax filings, ministerial submissions) must be notarised — and electronic notarisation requires QES.
- Specific regulated sectors with sector-specific QES rules
Some banking and insurance transactions under SAMA regulation require QES at execution. Check the specific circular before assuming AES suffices.
The B2B reality — and the workflow that handles it
Real Saudi B2B signing is a mixed-signer-pool problem. A typical procurement contract has one Saudi-national signatory on your side and a non-Saudi vendor representative on the other. A typical employment contract has a Saudi HR director and a foreign candidate who doesn't yet have an Iqama. The workflow that wins isn't "always QES" or "always AES" — it's "default AES, escalate QES when the document type demands it."
Classify the document type
Is this document on the QES-required list? (Court filing, real estate transfer, government tender, notarised POA, regulated banking instrument.) If yes, route to QES. If no, route to AES — which is most documents.
AES path: send to all signers via link + OTP
Counterparty receives a branded email, opens the contract in their browser, verifies with OTP, signs. No app install, no Nafath dependency. Works identically for Saudi and non-Saudi signers. Audit trail and PAdES-B-T seal satisfy ETL Article 5.
QES path: invoke Nafath only when required
For the narrow set of documents that require it, route the Saudi signer through Nafath via Absher push. Non-Saudi co-signers (if any) sign the same document at the AES tier where the document type permits a mixed-tier execution.
Single sealed PDF; clear audit trail
Output is one PDF with all signatures applied, PAdES-B-T sealed, with the audit trail recording which signer used which tier. Both AES and QES-bearing signatures carry the same legal effect for the parts of the document where ETL Article 5 conditions are met.
Side-by-side — what each tier actually buys you
AES — the recommended default
What roughly 95% of Saudi B2B contracts should be signed with.
- Works for every signer with an email and a phone — Saudi or otherwise, resident or not
- Satisfies ETL Article 5: unique linkage, sole control, tamper-evident binding
- Cryptographically sealed (PAdES-B-T), RFC 3161 timestamped, hash-chained audit trail
- Completion rates 91%+ in our Saudi customer cohort; sales cycles compress because non-Saudi counterparties don't get blocked
- Recognised in Saudi commercial courts as primary evidence since 2007
- No state API dependency: works during Nafath outages, works for offshore signers, works in cross-border deals
QES with Nafath — escalate when required
The right tool for the narrow set of state-facing documents that demand it.
- Available only to Saudi nationals and Iqama holders — structurally excludes ~30% of B2B counterparties
- Requires Nafath app install, push acceptance, and biometric authentication per signing event
- Completion rate ~18 points below AES because of added friction and signer-pool exclusion
- Carries the highest evidentiary weight — equivalent to a wet-ink notarised signature for state acts
- Legally mandated for Najiz court filings, MoJ real estate transfer, Etimad tendering, notarised POAs
- Dependent on Nafath uptime and Absher session state — adds an external failure surface to your workflow
Saudi ETL Article 5 doesn't grade signatures by national identity. It grades them by whether the signature uniquely identifies the signer, is under their sole control, and creates a tamper-evident link to the document. Every properly built AES implementation satisfies all three. QES adds a state-anchored identity certificate — useful where the receiving authority demands one, redundant where it doesn't.
— The statutory point most teams miss
What the migration looks like — concretely
The right path for a Saudi organisation isn't "switch entirely to QES" or "ignore QES". It's a two-tier policy that mirrors how the statute is actually structured. Build the default AES workflow first; layer the QES escalation on top for the narrow document categories that demand it.
Three-week migration playbook for a 50–500 person Saudi organisation
- Week 1 — classify your signed-document inventory
List the document types your organisation signs every month. Tag each as AES-sufficient or QES-required against the ResidencyTable above. For most organisations, only 2–4 document types fall into QES-required.
- Week 2 — deploy the AES default workflow
Stand up SahlSign (or equivalent ETL-compliant AES platform). Build templates for the highest-volume AES document types — employment contracts, NDAs, vendor agreements, sales contracts. Train the team. Most signing volume moves to AES inside 14 days.
- Week 3 — wire the QES escalation path
For documents that genuinely require QES (court filings via Najiz, real estate via MoJ, tenders via Etimad, notarised POAs), set up the Nafath-backed flow. This is a smaller, more specialised pipeline used by legal and procurement, not by the whole company.
- Ongoing — measure completion and time-to-signature by tier
Track AES vs QES completion rates and time-to-signature in your own data. The gap shows up immediately; the case for AES as default is empirical, not theoretical, by month two.
The takeaway
Nafath and QES are excellent for what they're for. They are not the right default for every contract a Saudi business signs — they were never designed to be, and the ETL does not require them to be. The statute is tiered for a reason: AES gives commercial signing full legal weight without forcing every signer through a sovereign-identity flow that only ~21 million people on the planet can use. The mature posture is AES as default, QES on escalation. It maps to the law as written, it accommodates the real signer pool, and it converts at materially higher rates than QES-everywhere.
of Saudi B2B signing volume sits in document categories where ETL Article 5 grants AES the same evidentiary weight as QES — and the same legal effect as wet ink. Defaulting to AES isn't a compliance shortcut; it's the configuration that matches what the statute actually requires.
SahlSign Saudi customer document-mix analysis, 2026
Related reading
- The Future of Identity and Signing in the Middle East — the broader Nafath / UAE Pass / QDI identity infrastructure that QES rides on, and where it's heading by 2027.
- Why Regional Hosting Matters for Sensitive Documents — Saudi PDPL (M/19 of 1443H) cross-border transfer rules that apply alongside signature tier choice.
- Is Electronic Signature Legal in Qatar? — adjacent jurisdiction; useful reference if your operations span both Qatar and Saudi Arabia.
Sources
- Saudi Electronic Transactions Law — Royal Decree No. M/18 of 1428H (2007)
- Implementing Regulations of the Electronic Transactions Law
- Communications, Space and Technology Commission (CST) — PKI and licensed CAs
- Nafath — National Information Center authentication service
- Absher — Saudi government services portal
- Najiz — Ministry of Justice e-filing portal
- Etimad — government procurement platform
- Saudi PDPL — Royal Decree No. M/19 of 1443H
- SDAIA — Saudi Data and AI Authority
- Saudi Vision 2030 — digital transformation programme