Sovereign deployment pathway
The sovereign deployment pathway area of the Readiness and Adoption programme explains how a government or institution operates the Nexus reference implementation on its own infrastructure: data residency, air-gapped operation, zero-trust identity, signed builds with SBOMs and provenance attestations, and how locally held records stay verifiable and interoperable with the global registry and resolver without surrendering control. Each artefact of the area carries a UNI (Unique Nexus Identifier).
- Nexus Standards: NS-9, NS-11, NS-12.
- Open standards: NIST SP 800-207 Zero Trust Architecture; Supply-chain Levels for Software Artifacts (SLSA) 1.1; Sigstore signing and transparency log; SPDX; CycloneDX; OpenID Connect Core 1.0 on OAuth 2.0; Decentralized Identifiers (DIDs) v1.0; Digital Public Goods Standard.
- Data and feeds: ROR data dump; World Development Indicators.
- Couples with: Sovereign stack; National adoption pathway; Zero-trust fabric; Software and supply chain.
- Nexus Standards
- 3
- NS-9, NS-11, NS-12
- Open standards
- 8
- named, never copied
- Data and feeds
- 2
- listed for reference
- Couplings
- 4
- with other areas
- UNI
- requested · allocation in progress
- Status
- Proposednot yet in the catalogue
- Last reviewed
- area profile
Nexus Standards (2026). Sovereign deployment pathway: area brief, Readiness and Adoption programme. Proposed. https://nexustandards.com/readiness/sovereign-deployment-pathway/. Last reviewed 17 October 2026.
Files include the credits and the licence statement and are generated in the browser; no data is transmitted. Downloads require JavaScript.
Scope and boundaries
An area of the Readiness and Adoption programme (readiness pathways). The area profile sets out 5 matters in scope and 3 matters addressed by other areas.
In scope 5
- Data-residency and air-gapped deployment records (contextual UNIs)
- Build provenance, signing and SBOMs for deployed components
- Zero-trust identity federation with the global resolver
- Synchronisation and verification of registry and catalogue data
- Local licence status and licence conditions
Out of scope 3
- Hosting services or procurement
- National security accreditation, which this pathway does not address
- Data-sharing agreements
Jurisdictions Application in each jurisdiction is a national decision, taken by the National Standards Council (NSC) with the competent national authorities.
Evidence, recognition and capital pathways
What each institution of the ecosystem draws from this area: The Global Centre for Risk and Innovation (GCRI Canada), as Secretariat, for evidence; The Global Risks Forum (GRF) for recognition; and The Global Risks Alliance (GRA) for capital.
GCRI Canada
Records produced in a sovereign deployment remain readable by the GCRI Canada evidence pathway when their provenance and signatures verify; GCRI Canada decides admissibility.
The Global Risks Forum (GRF)
A sovereign deployment’s contextual UNI and attestation trail can be cited in a GRF recognition record under GRF’s rules.
The Global Risks Alliance (GRA)
Projects operated on a sovereign deployment can present verifiable records to GRA, which decides capital readiness.
Each institution determines under its own rules what it accepts as evidence; a pathway reading is neither an approval nor investment advice.
From evidence to a decision
An artefact is identified and described; its evidence is assembled against the profile of this pathway; clauses are evaluated by an independent evaluator and attested; the evidence file is submitted by reference, and the deciding institution decides under its own rules. 8 operations in 5 phases, built from the area profile: the rows carry its own data sources, indicators, open standards, couplings and, where listed, hazards, and each operation names the rules it implements (14). Records and artefacts are cited by UNI (Unique Nexus Identifier) and version.
Standards · codify and correct
Standard lifecycle
Standard lifecycle · NS-13 track · Contribution channels · IETF track · W3C track · OGC track · OASIS track · ISO and IEC stages · Conformance · Record lifecycle · Routing · Monitoring.
Cycle findings become change proposals, the Global Standards Council adopts after a public last call, and each country decides its own adoption.
01 Route missions
- 01Route missions to standards and profilesStep · Nexus StandardsNexus Standards routes each candidate mission to the standards and profiles that apply.
02 Profiles and conformance
- 02Compose mission profilesStep · Nexus StandardsNexus Standards composes mission profiles and records any national adoption the missions depend on.
- 03Validate build outputs against the profilesStep · Nexus StandardsNexus Standards validates build outputs against the composed profiles and records the evidence.
- 04Monitor conformance and record sealed evidenceStep · Nexus StandardsDuring Action Week Nexus Standards monitors conformance and logs deviations.
03 Proposals and review
- 05Deviations and corrections become change proposalsStep · Nexus StandardsDeviations become change proposals, and the correction is recorded as a change to the evidence.
- 06Cycle findings become change proposalsStep · Nexus StandardsFindings from a cycle become change proposals: method and correction findings from Reports (F06) and docket items from Nexus…
- 07Draft and revise in the openStep · Committees and working groupsTechnical committees and working groups draft and revise the standards in the open process of NS-13.
- 08Review toward a council decisionStep · Nexus StandardsNexus Standards moves change proposals through review toward a council decision.
04 Council decision
- 09Public last callStep · Global Standards CouncilThe Global Standards Council adopts by a two-thirds majority after a ninety-day last call.
- 10Global adoption of a standardDecision · Global Standards CouncilThe Global Standards Council decides the adoption of each standard after public last call.
05 Publish and identify
- 11Assign a UNI and publishStep · Secretariat (GCRI Canada)Nexus Standards assigns UNIs and deposits publications under the publisher’s process.
- 12A UNI identifies and never certifiesRecord · Nexus StandardsEvery object of the programme year carries one identifier, a UNI under NS-1, so that it can be cited, versioned and resolved.
- 13Publish the year’s adopted changesStep · Nexus StandardsAt renewal Nexus Standards publishes the year’s adopted changes and national adoption status.
06 National adoption and application
- 14National adoption by the National Standards CouncilDecision · National Standards CouncilEach country’s National Standards Council decides national adoption: adopt as is, adopt with a profile (NS-16), adapt, or reference only.
- 15Adopted standards reach courses and editionsStep · Nexus StandardsEach adopted standard or profile becomes a course module in Risk Academy (F09), and standards are applied in Reports editions (R1).
- 16Adoption is final for each jurisdictionStandard · National Standards CouncilAdoption is final for each jurisdiction, and the GSC has no veto over a national decision. No global body holds a veto.
- 17National adoption recordsRecord · Nexus StandardsComposed mission profiles and national adoption records go to the Foundry at readiness preparation (F08).
Nexus Standards · Nexus Standards (institution) · National Standards CouncilAn outline of the designed programme cycle, not a record of operation: no cycle has run and every programme is at service level R0. Every Nexus Standard is at the PROPOSED stage and nexustandards.com governs the text and status of each one. A UNI identifies and never certifies; a validator report is evidence for review, not a conformance claim.
The operations, as a table
| Step | Phase | Operation | Who | Decision rule | Record | Implements |
|---|---|---|---|---|---|---|
| 01 | Identification | Artefact (start). What this pathway reads: Data-residency and air-gapped deployment records (contextual UNIs), Build provenance, signing and SBOMs for deployed components and Zero-trust identity federation with the global resolver. | the applicant institution | every artefact carries a UNI and its record | Data-residency and air-gapped deployment records (contextual UNIs) | NS1-R1, NS1-R4 |
| 02 | Identification | Context (step). Each programme or deployment is its own context. | the applicant institution | evidence belongs to its context; nothing is inherited | the contextual UNI of the programme or deployment (NS-9) | NS9-R1, NS9-R3 |
| 03 | Evidence | Evidence profile (model). Open references of this pathway: NIST SP 800-207 Zero Trust Architecture, Supply-chain Levels for Software Artifacts (SLSA) 1.1, Sigstore signing and transparency log and SPDX. | the pathway working group | the profile states what an artefact must carry to be readable as evidence | required fields, licence status and provenance depth; references such as NIST SP 800-207 Zero Trust Architecture | NS14-R2 |
| 04 | Evidence | Assemble (record). Data sources listed for reference: ROR data dump and World Development Indicators. | the applicant institution | evidence is cited by UNI and version; missing evidence is recorded as missing | record references, including ROR data dump | NS2-R2, NS11-R3 |
| 05 | Evaluation | Evaluate (exercise). The evaluator runs outside the applicant’s trust boundary. | an independent evaluator with a mandate | subject and evaluator are distinct; missing evidence is INDETERMINATE | attestations per clause | NS11-R1, NS11-R2, NS11-R3 |
| 06 | Evaluation | Report 17.6.1 (record). A report never states certification; it lists results and evidence. | the reporting service | the report is generated from attestations, with evaluator and instant | a generated report, with SDG 17.6.1 where relevant | NS11-R5, NS14-R3 |
| 07 | Submission | File by reference (step). The institution reads the records at the resolver, so it checks the current state independently. | the applicant institution | submitted by reference, never copied | the evidence file cited by UNI and version | NS2-R1, NS2-R5 |
| 08 | Decision | Institution decides (end). Records produced in a sovereign deployment remain readable by the GCRI Canada evidence pathway when their provenance and signatures verify; GCRI Canada decides admissibility. | the deciding institution | the institution decides under its own rules; a standard makes no one ready | the institution’s decision, recorded by reference | NS13-R4, NS14-R3 |
Table.Operations in walking order; each row names the phase, the operation, its actor, its decision rule, the record it leaves and the rule identifiers it implements. The table shows the process as specified; it does not report the status of any standard, proposal or record. Sources: NIST SP 800-207 Zero Trust Architecture · Supply-chain Levels for Software Artifacts (SLSA) 1.1 · NS-9: Contextual UNIs · NS-11: Verification and monitoring.
Standards that apply
The area profile lists 3 Nexus Standards. Each is a proposed standard under development.
- 01
NS-9 · Contextual UNIs (deployments, instances, programme instances)
Status: proposed · 5 requirements stated. Read NS-9.
- 02
NS-11 · Verification and monitoring (evidence, attestations, zero-trust conformance observation)
Status: proposed · 6 requirements stated. Read NS-11.
- 03
NS-12 · Software, model and AI/ML artefacts (supply chain, model cards, dataset sheets)
Status: proposed · 4 requirements stated. Read NS-12.
How a shock travels through this system
A system model of this area built from the registry: 5 systems, 4 sectors, 9 controls, 2 feeds, 2 indicators. Select the components to include, choose an initiating hazard and run the scenario. Stress propagates through the hazard relations of the Nexus Hazard Standard (NHS-1), the exposure of each system, the recorded couplings and the sectors that carry the loss; adopted standards dampen transmission and live data sources support detection. All parameters are stated assumptions that the reader can adjust; results are illustrative scenario outputs for exercises and training, not forecasts or risk assessments.
Systems and couplings
- Sovereign deployment pathway
- Sovereign stack Coupling
- National adoption pathway Coupling
- Zero-trust fabric Coupling
- Software and supply chain Coupling
Controls
NS-9Contextual UNIs (deployments, instances, programme instances)NS-11Verification and monitoring (evidence, attestations, zero-trust conformance observation)NS-12Software, model and AI/ML artefacts (supply chain, model cards, dataset sheets)NRS-A4Zero-trust verification of standards and conformanceNRS-A6One-click deployment and adoption kitsNRS-T7Digital identity and trust infrastructure riskNRS-H93Hazard family: Identity, trust and cryptographic failure (NHS-1 cyber.identity)NRS-H106Hazard family: Space technology and orbital infrastructure (NHS-1 tech.space-systems)NRS-H107Hazard family: Digital infrastructure concentration and monoculture (NHS-1 tech.digital-concentration)
Observation
- ROR data dump (listed for reference)
- World Development Indicators (listed for reference)
- Fixed broadband subscriptions per 100 inhabitants, by speed
- Proportion of individuals using the Internet
Systemic couplings
4 couplings link this area to other areas and programmes, each with the mechanism of the link.
- Sovereign stackOpen Infrastructure and DevelopersThe self-hostable reference deployment is specified in the infrastructure area.
- National adoption pathwayReadiness and AdoptionNational adoption commonly requires in-country hosting.
- Zero-trust fabricTrust, Verification and AssuranceIdentity, mandates and mutual authentication make a sovereign deployment trustworthy to others.
- Software and supply chainTrust, Verification and AssuranceSigned builds, SBOMs and provenance attestations let a sovereign operator verify what it runs.
Routing, monitoring and verification tools
Deployment
Reference deployments and a sandbox with worked examples.
Available · from the registryVerification console
Test suites, conformance statements and attestations for each standard, as recorded in the registry.
In progressMonitoring console
Version and source status for each standard, as published by the issuing bodies.
Each console computes from the registry and states its reasoning; decisions remain with the competent bodies.
Open standards referenced
8 open standards, each with its relation as recorded in the register under NS-14. Hover over or focus a relation for its definition.
adopt5
NIST SP 800-207 Zero Trust ArchitectureNISTlisted in the register · nist-sp-800-207Supply-chain Levels for Software Artifacts (SLSA) 1.1OpenSSF (Linux Foundation)listed in the register · slsaSigstore signing and transparency logOpenSSF (Linux Foundation)listed in the register · sigstoreSPDXSPDX project (Linux Foundation)listed in the register · spdxOpenID Connect Core 1.0 on OAuth 2.0OpenID Foundation and IETFlisted in the register · oauth2-openid-connectIndicators
The area profile names 2 indicators, each with its framework and code.
Indicator names and codes are given as published by their stewards.
Data sources
2 data sources named in the area profile, each with provider, licence, update frequency and delivery path.
Data sources are listed for reference; live data is displayed once licence review is complete.
- Live
- 0
- on completion of licence review
- Listed in the data register
- 1
- licence terms recorded
- Proposed for the register
- 1
- licence terms to be recorded
- Delivery
- 1 governed service · 0 plugin · 0 browser · 1 snapshot · 0 listed for reference
- proposed paths in order of preference: governed data service, plugin, direct browser read, build-time snapshot; sources whose terms do not permit reuse are listed for reference only
World Development Indicatorsfor reference
World Bank · annual with quarterly updates
CC BY 4.0
governed data servicelisted in the data register.
ROR data dumpfor reference
Research Organization Registry · monthly
CC0 1.0
build-time snapshotproposed for the data register
Intended users
The area profile identifies 4 user communities.
- Government digital agencies
- National data centres
- Institutions with residency obligations
- Developers and operators
Working group charter
A proposed charter for this area, open to institutions and experts.
Describe the sovereign deployment profile and how sovereign instances stay verifiable and interoperable.
Institutions and experts are invited to charter this working group under NS-13 by filing a public change record. National Working Groups (NWGs) contribute national inputs and field exercises through their National Nexus Consortium (NNC).
- Sovereign deployment profile (residency, air-gap, identity federation)
- Build provenance requirements on SLSA and Sigstore
- Synchronisation protocol for registry data
- OpenSSF liaison sought
- Digital Public Goods Alliance liaison sought
- OpenID Foundation liaison sought
- W3C DID Working Group liaison sought
Open research questions
3 questions identified as priorities for the working group.
- Air-gapped operation conflicts with transparency logs that assume online verification.
- Identity federation across sovereign instances lacks an agreed trust framework.
- Data-residency law varies and can restrict even metadata synchronisation.
Restricted compatibility profiles
Standards whose text is not openly available are named and linked only. Any compatibility profile is kept on protected pages until an arrangement with the issuing body is in place.
The working group may identify restricted standards relevant to this area; they are listed here by name and link.
Hazards, threats and sectors concerned
Hazards and threats 0
This area draws on the hazards of the areas it is coupled with.
Sectors 0
This area serves all sectors through the areas it is coupled with.
Sources
4 references from peer-reviewed and official publications cited in the area profile, linked at the publishers’ own sites.
- officialSecure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218)NIST · 2022
- officialZero Trust Architecture (NIST SP 800-207)NIST · 2020
- standardVerifiable Credentials Data Model v2.0 (W3C Recommendation)W3C · 2025
- standardOpenStand: Principles for the Modern Standards Paradigm (RFC 6852)IETF / RFC Editor · 2013
Recent research on this area
Recent peer-reviewed articles, preprints, datasets and reports on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex, Crossref, DataCite, Zenodo, arXiv, Europe PMC, OpenAIRE Graph) with search terms composed from the registry. Each work is listed with its authors, venue, year, type, open-access status and licence, and links to its DOI or landing page. Sources not yet enabled for live display on this site are listed for reference and are not queried.
Search termsdigital sovereignty; data sovereignty; digital public infrastructure; Sigstore signing and transparency log; SPDXDerived from the title and scope of the area, the NHS-1 hazards it names and the open standards it lists.
- OpenAlexlisted for reference; not queried
- Crossreflisted for reference; not queried
- DataCitelisted for reference; not queried
- Zenodolisted for reference; not queried
arXivlisted for reference; not queried- Europe PMClisted for reference; not queried
- OpenAIRE Graphlisted for reference; not queried
No source is enabled for live display on this site yet: the sources are listed for reference and none is queried. Once the publisher of record enables a source after its terms are reviewed, recent works are listed here. Metadata and links only: title, authors, venue, year, type, open-access status and licence as each source records them; works are listed for orientation, not reviewed or endorsed.
Risk Academy courses and disciplines
1 course and 4 disciplines of Risk Academy (risksacademy.com) that teach the knowledge and methods of this area. Each course lists its level, stream and learning hours.
Courses
Disciplines
The correspondence between courses, disciplines and the Nexus Standards is maintained with Risk Academy and is subject to its academic review.
Programmes, tracks and courses for this area
GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA) and Risk Academy work on the subject of this area in distinct roles (research and evidence; governance, policy and convening; capital, finance and markets; education and training). Each entry states why it corresponds and the step it offers; each institution sets its own terms of participation.
Research and evidence
GCRI Canada
Research programmes that produce the observations, models and assessments these records describe.
Digital Public InfrastructureStudies public cloud and concentration.Apply to this programme Data and ComputeEngineers public-interest data infrastructure.Apply to this programme therisk.globalAll programmes of GCRI CanadaGovernance, policy and convening
The Global Risks Forum (GRF)
Tracks that convene public authorities, researchers and institutions on the governance of shared risks.
AI and Digital GovernanceExamines digital dependence.Join this track globalriskforum.comAll tracks of The Global Risks ForumCapital, finance and markets
The Global Risks Alliance (GRA)
Industry programmes in which financial institutions build a shared understanding of systemic risk.
Development Finance NexusWorks on country programme readiness and the evidence development finance requires.Join this programme Disaster Risk FinanceWorks on financing evidence and due diligence.Join this programme globalriskalliance.comAll programmes of The Global Risks AllianceEducation and training
Risk Academy
Courses and disciplines that teach the knowledge and methods practitioners need to apply these standards.
Technology and DataRAT-204 · Intermediate · 19 learning hoursManaging risk data, AI, digital infrastructure and technology risk responsiblyTake this course All courses and disciplinesListed in the education and training section of this pageKey terms
- UNI
- Unique Nexus Identifier: a persistent identifier that resolves an artefact to its record.
- proposed
- A draft in the open development process that the Global Standards Council has not yet adopted. Each area profile is a proposal to the Nexus Standards registry.
- adopt
- Relation in which the external standard is used as published and values are validated against it.
- crosswalk
- Relation in which clauses of these standards are mapped to parts of the external standard by clause number, without reproducing its text.
- profile
- Relation in which a Nexus profile narrows or extends the external standard for a defined use, validated with the issuing body’s own tools where these exist.
- change record
- A public record of a proposed change under NS-13, decided by the editors with written reasons.
- attestation
- An evaluator’s recorded result for one clause and one subject under NS-11.
- liaison sought
- A liaison the working group intends to request from the issuing body; a liaison is established only when the body confirms it in writing.
Related areas
Recent research and sources
Peer-reviewed articles, preprints, reports and datasets on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex and Crossref) and listed with authors, venue, year, type and access status, with a link to each work. Curated references and related standards are listed first; recent works matched by subject follow and are listed for orientation.
Curated references
- Zero Trust Architecture (NIST SP 800-207)
NIST · 2020 · Official publication - Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218)
NIST · 2022 · Official publication - Verifiable Credentials Data Model v2.0 (W3C Recommendation)
W3C · 2025 · Standard - OpenStand: Principles for the Modern Standards Paradigm (RFC 6852)
IETF / RFC Editor · 2013 · Standard
Related standards and frameworks
- NIST SP 800-207 Zero Trust Architecture
NIST - Supply-chain Levels for Software Artifacts (SLSA) 1.1
OpenSSF (Linux Foundation) - Sigstore signing and transparency log
OpenSSF (Linux Foundation) - SPDX
SPDX project (Linux Foundation) - CycloneDX
OWASP CycloneDX; Ecma International TC54 - OpenID Connect Core 1.0 on OAuth 2.0
OpenID Foundation and IETF - Decentralized Identifiers (DIDs) v1.0
W3C DID Working Group - Digital Public Goods Standard
Digital Public Goods Alliance
Search terms, derived from the title and scope of the area: digital sovereignty; data sovereignty; digital public infrastructure. With JavaScript enabled, recent works matching these terms are listed from OpenAlex and Crossref.
Questions and answers.
What is the status of the Sovereign deployment pathway area?
How are data sources presented?
How can this brief be amended?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-STDSend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsNexus StandardsSee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Contribute to Sovereign deployment pathway
Institutions and experts are invited to propose amendments, join the working group or propose data sources. National participation is organised through each country’s National Nexus Consortium (NNC) and its National Working Groups (NWGs); competent national authorities are engaged through official channels.
Status and use. The Nexus Standards are proposed standards developed through an open process under NS-13 and published for voluntary use; they do not constitute certification, accreditation or regulatory approval, and adoption remains a decision of the Global Standards Council and, in each country, of its National Standards Council. A UNI (Unique Nexus Identifier) identifies an artefact; it does not certify it. Names of standards bodies and their standards belong to their stewards and are used only to identify the documents; no text of an external standard is reproduced here. Nexus Standards is not affiliated with, endorsed by or certified by any standards body named here.
Licences: CC BY 4.0 for standards text, registries, schemas and data; Apache-2.0 for reference code. External standards are cited by name, number and link under their own licences. Third-party data, libraries and fonts keep their own licences: see Third-party notices.