Encrypted ISO / image
Hosted in customer-controlled or approved private object storage and delivered over HTTPS, prepared USB media or a qualified network boot path.
Encrypted software, not exposed signing keysYOUR ORGANISATION. YOUR KEYS. YOUR DEVICES.
Secure your systems.
Keep the control.
From your first approval to your next device update. Explore a simpler way to give your organisation control over what runs, who approves it and how every device stays within policy.
Explore your deployment Proposed enterprise platform
Interactive walkthrough
Interactive walkthrough
Your organisation
NØNOSAPPROVED AUTHORITY
Your device fleet
One journey. Three customer-held signing keys. Multiple deployment paths.
01 / START WITH YOUR ORGANISATION
“I want to secure
our systems.”
Choose the organisation you are protecting. The security foundation stays the same. Your people, approval rules and deployment choices make it yours.
Your company sets the rules for its workforce, devices and approved software.
Your organisation
Owns the approval policy and chooses the people allowed to change it.
Your devices
Join a defined fleet with an identity and a policy they can verify.
Your software
Runs only within the capabilities the device’s trusted software grants.
02 / PUT AUTHORITY IN THREE HANDS
Three signers.
One shared decision.
Choose three authorised people or customer-controlled signing systems. In a 3-of-3 policy, all three approve a governance change. No single signer can change the rules alone.
Interactive demonstration · no wallet connection
0 / 3 approvals · Select each signer to approve the example policy.
Your keys stay with you.
Each signer approves a challenge in their own wallet or hardware wallet. Private keys, recovery phrases and wallet passwords never belong in a website, boot screen or policy ledger.
Decide key rotation and recovery before rollout. A 3-of-3 rule protects shared authority but losing one required signer can block future changes. Approved devices can boot automatically within an already authorised policy; the three signers approve changes rather than every startup.
03 / TURN APPROVAL INTO A VERIFIABLE POLICY
Your policy.
Your contract.
The proposed policy contract records who can approve changes and which policy version is authorised. Your fleet can check that record without giving an outside provider ownership of your signing keys.
Company policyEXAMPLE
Approval rule3 of 3 authorised signers
Authorised releaseSigned manifest + image hash
Device admissionEnrolled devices under your policy
Policy lifecycleVersion, expiry, rotation & recovery
Awaiting the three demo approvals
On the blockchain
Approval state, authorised versions and integrity commitments. A shared record your devices can verify.
Under your control
Signer keys, customer policy and the choice of deployment and key-release infrastructure.
04 / CHOOSE HOW YOUR DEVICES START
One policy.
Your way to deploy.
A desk, a data centre or a remotely managed fleet. Choose a path to see how an approved environment could reach your devices.
Approved imageVerify before runningUSB boot
Proposed deployment workflow
A controlled environment, ready to carry.
Prepare approved boot media for compatible test hardware. The trusted startup path checks the authorised image before the protected environment runs.
- Prepare an approved USB image
- Boot compatible hardware
- Verify the release and enrol the device
05 / DELIVER THE SOFTWARE, PROTECT THE KEYS
Encrypted in transit.
Verified before trust.
The software image travels through your chosen storage and delivery system. The blockchain provides a verifiable approval record. They do different jobs.
Policy & integrity record
Version, manifest hash and authorisation commitments identify the approved release. Sensitive customer data and decryption secrets stay off-chain.
Verifiable approvals, not a public software diskA key released to an authorised device
Your release service verifies enrolment and device identity, plus supported attestation where available, before releasing a wrapped image-decryption key.
How verified boot and device key release work
A signed UEFI bootstrap follows the configured trust chain and verifies the authorised manifest signature and encrypted image hash. After enrolment checks, the release service wraps the image-decryption key to a device-held key, using a TPM or another supported secure key store where available.
The approved device can then decrypt and verify the software before execution. Hardware qualification must define supported attestation, anti-rollback controls and online or offline boot policy. None of these steps asks an operator to type a wallet private key or recovery phrase.
06 / GIVE EACH DEVICE A VERIFIED IDENTITY
Join the fleet.
Keep the boundaries.
Enrolment connects a device identity to your organisation’s policy, for example through an approved pairing step. At startup, trusted device software verifies the release and applies the approved rules locally.
Illustrative device check
Workstation 001
- 01Device identityReady to check
- 02Approved releaseReady to check
- 03Image integrityReady to check
- 04Local policyReady to check
A demonstration of the proposed enrolment flow. Your actual device is not inspected.
Verify identity
Admit software from an approved, verifiable source.
Separate memory
Give each capsule its own virtual address space.
Limit authority
Check privileged actions against explicit capabilities.
07 / MANAGE WHAT HAPPENS NEXT
Change the policy.
Keep your authority.
Your signers approve a new policy or release. Devices retrieve the authorised version through an outbound connection or your delivery infrastructure, then verify and enforce it locally.
Your example fleet policy
INTERACTIVE DEMOChanges require the configured signer approvals before they become authorised.
Less network complexity
Outbound policy retrieval can reduce the need for a management VPN. Private applications and internal services may still need their own connectivity.
Controlled updates
An update channel or polling service carries the approved change. Devices verify policy validity, expiry and revocation information before enforcing the applicable rules locally.
YOUR NEXT STEP
Design your first
controlled deployment.
Bring your device estate, your security requirements and your approval model. We can explore the right evaluation path together.
Let’s talk about your fleetPlatform availability & deployment scope
This walkthrough describes a proposed enterprise onboarding and fleet-management platform. Current public NØNOS development work targets selected x86_64 / UEFI platforms. The public installer does not install a complete operating system to an internal disk or provide the fleet updater shown here. Mobile integration is planned and depends on platform-specific engineering. Production deployment requires hardware qualification, security review, supported recovery procedures and an agreed operating model.
Explore current software and documentation ↗