Your keys. Your policy.
Your devices.
A proposed management layer for customer-approved group policies, encrypted software deployment and a verifiable record of authority. Manage devices wherever they connect, while keeping operational control with your organisation.
Public software and verification artifacts exist. The complete blockchain fleet service, licensing and managed deployment workflow below remain proposed.
Customer authority
Approval stays with your organisation.
Private distribution
Encrypted software stays off-chain.
Local enforcement
The endpoint verifies before applying.
A shared record of
what was authorised.
Customers, service providers and auditors could check the same history of policy approvals.
Policy provenance
Record an approved policy’s fingerprint, version and authorising organisation so later changes can be detected.
Deployment coordination
Reference an approved software manifest and rollout policy, then distinguish approval from actual installation using device receipts.
Reviewable entitlements
Explore organisation-scoped subscription records that customers can inspect and reconcile against their contracts.
A shared ledger is useful when several parties need a consistent approval record. A signed central registry may be sufficient for an organisation with a simpler trust model.
Publish the approval.
Verify at the device.
Approval, confidential delivery and local enforcement each have a distinct role.
From organisation to endpoint.
Proposed architectureOrganisation group: Finance / Tier 1. Policy epoch 42. Capsules and capability ceilings approved.
The service must validate chain identity, finality and anti-rollback state; a reachable RPC is not by itself trustworthy.
Interactive design proposal only. No real devices or policies are changed. Full fleet management, recovery and blockchain integration remain engineering and validation work.
Proposed workflow. A published registry change does not by itself install software, grant a process permission or prove that a device applied the policy.
Record approval
Policy commitments, authorised signers, version history and finality.
Deliver privately
Signed policy bundles and encrypted software over authenticated transport.
Enforce locally
Verify authority and integrity, apply permissions, then return a signed result.
Exclusive control starts
with customer-held keys.
In the proposed customer-controlled configuration, only your organisation’s approved signing authorities could authorise fleet policy or software activation.
A provider could prepare and distribute changes. Operating the service, hosting a repository or holding a subscription would not itself grant permission to activate them.
A familiar workflow.
A reviewable history.
Organise devices by site, workload or assurance level. Give a finance workstation a different policy from a kiosk or AI research node.
| Policy area | Customer decision |
|---|---|
| Approved software | Which signed publishers, capsule measurements and releases may run |
| Process authority | Which declared capabilities an approved workload may receive |
| Device membership | Which organisation and groups may manage an enrolled endpoint |
| Rollout rings | Which evaluation devices receive a release before wider deployment |
| Update windows | When to stage, activate or require an approved restart |
| Expiry and revocation | How long cached policy remains valid and how withdrawn access is handled |
| Recovery | Who can approve replacement keys or restore an authorised configuration |
This is a proposed NØNOS policy model. Windows Group Policy compatibility, Microsoft Entra and existing MDM integrations require separate engineering and validation.
Private software.
Verified delivery.
The proposed model encrypts packages before repository storage. Only the intended organisation or device receives the corresponding decryption authority. Signed manifests provide a separate check of publisher approval and package integrity.
The ledger contains a fingerprint or commitment. Application binaries, passwords and decryption keys stay off-chain.
Key rotation, device removal and recovery must be designed and tested. Revocation cannot make an already copied or decrypted package disappear.
The device checks
before it trusts.
Verification at execution
The public microkernel describes a bootloader that verifies the kernel, a capsule admission gate and capability checks at the system-call boundary. These checks operate locally.
Customer-approved rollout
A fleet layer would connect approved organisation policy to those checks. Devices would verify and stage a change before activation, following maintenance windows and recovery rules.
A registry event could prompt a connected device to retrieve an update. The chain does not carry the full package or directly execute code on the computer.
Current dependency: the official v0.9.2 roadmap describes the installed-system update path as future work, with unattended updates in the v0.9.6 scope. End-to-end enterprise updating therefore remains proposed. Read the roadmap ↗
Policy retrieval
without a site-to-site VPN.
The proposed endpoint retrieves signed policy through an outbound authenticated internet connection, verifies it locally and enforces the resulting permissions.
This could remove the need to build a site-to-site VPN solely to deliver management policies to remote devices.
Connectivity still matters
VPNs, private links or other controls may remain appropriate for business applications, private repositories and regulated networks.
Offline devices cannot receive an immediate instruction. Reconnection, polling, registry finality and local checks affect the time needed to apply a change.
A subscription model
the customer can inspect.
A proposed recurring service for fleet policy, release maintenance, deployment coordination, support and operational evidence.
Who can act?
Device authority comes from approved organisation identities and local policy. A tradable token balance must not grant fleet administrator access.
What is covered?
A service agreement defines covered organisations, device groups, service levels and subscription periods. A future registry could make those rights verifiable.
What is proposed?
Any NOX role needs a separately published product and commercial specification. This page does not announce compulsory token purchases or revenue-sharing rights.
Private commercial details would remain off-chain. Open-source licence obligations are separate from paid service entitlements. Explore proposed plans and pricing ↗
Private operations.
Reviewable commitments.
| Information | Proposed location | Purpose |
|---|---|---|
| Policy fingerprint, version and signer commitment | Registry or ledger | Review the history of approvals |
| Organisation identities and device inventory | Customer-approved private system | Protect operational and personal information |
| Full policy and encrypted software | Authenticated repository | Deliver required content to an endpoint |
| Signing and decryption keys | Customer-controlled key infrastructure | Preserve authority and confidentiality |
| Admission and capability checks | Endpoint | Enforce permissions locally |
| Detailed device receipts and logs | Private evidence store | Confirm rollout outcomes and exceptions |
| Optional receipt-batch commitment | Registry or ledger | Check evidence integrity without exposing raw logs |
Designed for
the difficult days.
What if the internet or chain is unavailable?
The proposed design uses previously verified local policy within its approved validity period. Expiry and degraded-operation behaviour must be defined for each environment. Clinical and industrial devices need an operationally safe fallback. Offline devices cannot learn fresh revocations until they receive a trustworthy update.
Can an AI agent approve its own access?
The intended design separates the workload from policy-signing authority. An agent receives only the capabilities its approved capsule and customer policy allow. Correct implementation, protected approval keys and least-privilege policy remain essential. Harmful actions within legitimate permissions still need application controls and human oversight.
Does a confirmed transaction prove every device applied the policy?
No. It records a registry action. Endpoint identity, local verification and rollout receipts are separate requirements. Transactions need block inclusion and finality; they are not an instant device command channel. Ethereum transaction lifecycle ↗
How are old policies prevented from being replayed?
The proposed design needs a monotonic version floor, reliable local state, trusted timestamps or counters where available, explicit expiry and verified finality. Offline rollback resistance must not be assumed when trustworthy persistence or time is absent.
What does the ledger not solve?
It does not decide whether a policy is sensible, secure a stolen administrator key, restore leaked secrets, repair a compromised enforcement layer or update an offline computer. Contract correctness, key recovery and endpoint qualification remain necessary.
Is blockchain mandatory for every customer?
No deployment mode is confirmed here. Public-chain, permissioned and signed-registry approaches should be evaluated against customer governance, privacy, cost and availability requirements.
Public foundations.
A service to qualify.
| Layer | Current position |
|---|---|
| Signed capsule admission and capability checks | Documented in the public microkernel source |
| Release verification artifacts | Described and linked by the official software site |
| Installed-system updates | Future work in the current official roadmap |
| Blockchain registry and enterprise fleet console | Proposed; no end-to-end shipped service established by reviewed sources |
| Customer-held fleet keys, encrypted distribution and recovery | Proposed service requirements requiring implementation and validation |
| Token-based entitlements and commercial pricing | Proposal requiring a published product and commercial specification |
Research from 2026. Software overview ↗ Public source ↗ Roadmap ↗
Design the control plane
around your organisation.
Discuss your device estate, approval model, deployment requirements and the evidence your team needs before a pilot.