TL;DR: Saudi entities and enterprises can now access 70+ government-issued digital identities worldwide through a single compliant API, replacing document-based checks with verified credentials and extending trust across borders, according to Hopae. The governance issue shifts from collecting documents to deciding how home-country identity evidence is accepted, logged and bounded inside local service flows.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Hopae's report: Saudi entities and enterprises gain access to 70+ government-issued digital identities through a single compliant API, shifting onboarding from document checks to wallet-based verification.
Why it matters: That matters because identity assurance, not document handling, becomes the control boundary for cross-border onboarding, fraud reduction and policy enforcement in regulated environments.
By the numbers:
- Saudi organisations will gain access to 70+ government-issued digital identities worldwide through Hopae Connect.
Context
Digital identity verification lets a service confirm a person by checking a trusted credential issued by an authority rather than by inspecting scanned documents. In cross-border onboarding, that changes the control problem from document authenticity to assurance mapping, wallet trust and attribute handling.
Saudi Arabia's service environment makes this especially relevant because visitors, workers and residents arrive with different national identity systems and assurance levels. When a platform can accept recognised credentials from multiple jurisdictions, the main governance question becomes how to maintain sovereignty, auditability and consistent access decisions across those identities.
Key questions
Q: How do identity wallets support cross-border onboarding?
A: Identity wallets support cross-border onboarding by letting a person present verifiable credentials issued under a recognised trust framework, so the relying party can verify issuer trust, signature validity and attribute provenance without handling the source identity system directly. Acceptance usually depends on scheme rules, assurance level, revocation status and whether the wallet can prove possession of the credential.
Q: What controls should govern foreign eID acceptance?
A: Foreign eID acceptance should be governed by mapped assurance levels, issuer and scheme trust tiers, attribute minimisation, cryptographic verification, revocation checking and explicit policy for which transactions require step-up checks. The relying party should also define jurisdictional limits, audit evidence and fallback handling when the foreign credential does not meet the local assurance threshold.
Q: How is wallet-based verification different from document checking?
A: Wallet-based verification confirms a credential presented from a digital wallet by checking cryptographic signatures, issuer provenance and holder control, rather than examining a physical or scanned document. Document checking reviews the evidence on the document itself, while wallet verification relies on trusted issuance, revocation status and presentation protocols.
Q: What happens when one API brokers many national identity systems?
A: When one API brokers many national identity systems, it acts as a federation or integration layer that normalises authentication, attribute release and response formats across multiple source authorities. The main risks are policy drift, inconsistent assurance, overbroad data sharing and weak revocation handling, so access rules and audit logs must be centralised.
Technical breakdown
How eID verification works through a single API
A verification hub aggregates multiple government eID and wallet connections behind one interface, but the security value comes from standardising request, response and validation flows. The relying party does not need to build separate integrations for every issuer, yet it still must interpret assurance level, credential provenance and the attributes released for each transaction. That means the API is not the trust source. It is the transport for trust decisions made against external identity systems and policy rules. See the Digital Identity, eID and Identity Wallets Guide.
Practical implication: Treat the API as a federation and policy layer, then validate which issuers, attributes and assurance levels are actually acceptable for each use case.
Why wallet-based onboarding changes identity assurance
Document-based checks rely on images, transcription and human judgement, which are weak controls when the real question is whether a credential was issued by a trusted authority and is still valid. Wallet-based verification shifts the proof source to a signed digital credential and can reduce manual review, but it also introduces dependence on issuer trust, revocation handling and selective disclosure. In practice, the organisation must define what evidence is sufficient for access, compliance or service entitlement. See the UK Digital Verification Services Trust Framework Guide.
Practical implication: Use issuer trust policies and attribute minimisation rules instead of designing onboarding around scanned documents.
Cross-border identity trust and sovereignty
Cross-border identity systems create a governance problem because the relying party is consuming identity evidence governed by another jurisdiction's rules. That requires clear policy on which foreign credentials are accepted, what data is stored, and how local service decisions remain sovereign even when the identity proof originated elsewhere. This is similar to any federated identity relationship, but with stronger assurance and legal-compliance implications because the credential is a government identity token, not a commercial account proof.
Practical implication: Map every accepted foreign identity source to an explicit trust policy, retention rule and service decision boundary.
Breaches seen in the wild
- Poland ArcGIS password leak 2023: An ArcGIS login emailed in 2020 was published from stolen mail in 2023 and still worked, exposing Polish military and infrastructure maps.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Verified identity, not document collection, becomes the governing control. The core shift here is that onboarding decisions move from visual document review to acceptance of externally issued digital identity evidence. That reduces fraud opportunity and manual error, but only if the relying party defines issuer trust, assurance thresholds and attribute release rules with the same discipline used for privileged access. The practitioner conclusion is simple: treat identity proofing as a policy decision, not an intake task.
Cross-border identity acceptance creates a sovereignty question. When an organisation accepts a foreign eID, it is delegating part of its assurance chain to another government's identity infrastructure. That is valuable for mobility and service access, but it also means local governance must bound what data is retained, what claims are trusted and when a credential is sufficient for high-risk transactions. The practitioner conclusion is to separate trust in the credential from trust in the entire user journey.
Digital identity interoperability is becoming an access-control issue. Once multiple national wallets can be accepted through one API, the real risk is inconsistent assurance policy across systems and teams. Without shared acceptance criteria, one service may trust a credential that another would reject, creating policy drift and audit gaps. The practitioner conclusion is to standardise trust decisions before scaling interoperability.
Global eID acceptance pushes identity governance closer to federation operations. This is not just an onboarding enhancement; it is a change in how identity evidence is brokered between jurisdictions and enterprises. The strongest programmes will define who may consume which issuer, under what assurance level, and for which business event, then enforce that consistently across channels. The practitioner conclusion is to manage foreign eIDs as governed federation relationships, not ad hoc integrations.
What this signals
Assurance mapping will matter more than integration count. As more national identity systems become reachable through shared APIs, the limiting factor is no longer connectivity. The limiting factor is whether every issuer, claim and assurance level has a clear local policy boundary, because interoperability without policy discipline becomes governance drift.
Federated identity design is moving into frontline operations. Teams that handle onboarding, fraud prevention and service access will increasingly need to distinguish between proof of identity and permission to proceed. That separation is the practical control that keeps cross-border trust from becoming uncontrolled access.
For practitioners
- Define accepted issuer trust tiers List which government-issued eIDs and wallets are acceptable for each journey, then bind each issuer to a documented assurance tier and business purpose.
- Separate proofing from authorisation Use the external credential to establish identity, then apply local policy to decide whether that identity is eligible for the specific service, transaction or access path.
- Minimise released identity attributes Request only the attributes needed for the transaction, and avoid storing raw identity evidence unless retention is required for compliance or dispute handling.
- Test revocation and fallback paths Validate how the service behaves when a wallet is revoked, unavailable or only partially trusted, including the manual fallback for high-risk onboarding.
Key takeaways
- Cross-border eID verification changes onboarding from document inspection to governed trust in digitally issued identity evidence.
- The hardest problem is no longer connectivity to multiple identity sources. It is consistent assurance mapping, attribute release and revocation handling.
- Organisations that accept foreign credentials need clear trust tiers and service boundaries, or interoperability will create policy drift.
Related NHI Mgmt Group resources: Digital Identity, eID and Identity Wallets Guide · UK Digital Verification Services Trust Framework Guide · Digital Identity Ethics
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C — Federation | The piece centres on accepting externally issued digital identities through a brokered trust relationship. |
| SP 800-63A — Enrollment and Identity Proofing | Cross-border eID acceptance still depends on proofing and evidence quality before trust is extended. | |
| Recommendation — Define federation trust policies for which issuers, claims and assurance levels your organisation will accept. Map each accepted credential source to an identity proofing standard and document its assurance level. | ||
| GDPR | Art.5 — Principles relating to processing of personal data | Identity verification here involves personal data, minimisation and purpose limitation across jurisdictions. |
| Recommendation — Limit identity data collection to the minimum needed and document purpose, retention and transfer rules. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The service must turn verified identity into consistent access decisions across journeys and systems. |
| Recommendation — Bind each accepted identity source to a consistent authorisation policy for the relevant business event. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Accepted digital identities still need explicit access-control policy and governance. |
| Recommendation — Document who can accept foreign identities and under what conditions access is granted. | ||
Key terms
- Digital Identity: Digital identity is the set of attributes, credentials, and access relationships used to authenticate and authorize a person, service, workload, or automated system. In security operations, it becomes the control layer that determines what can act, where it can go, and how far compromise can spread.
- Electronic Identity: Electronic identity is the digital representation of a person, device, workload, or agent used to authenticate and authorize access to systems and data. In IAM, it typically includes identifiers, credentials, attributes, and assurance evidence that link actions to a specific entity across applications, networks, cloud services, and security controls.
- Identity Wallet: An identity wallet is a user-controlled container for verified identity attributes or credentials that can be reused across applications. It aims to reduce repeated proofing and login friction, but it also concentrates trust, so issuance, revocation, and recovery controls become central to its security posture.
- Federation: Federation is the arrangement that lets one organisation accept identity assertions from another trusted identity provider. It reduces separate credentials, but it also creates dependency on token validation, trust configuration and certificate or key management. Defenders should check claims, audience restrictions, signing keys and trust relationships.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners translate identity trust decisions into durable controls across access, lifecycle and assurance.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org