Assurance and validation
What has been tested, and what has not been independently assured.
A security claim verified only by the people who wrote it is a starting point, not an assurance position. This page separates the two, so an evaluator can see the boundary without asking for it.
- Test evidence
- Independent assurance
- Certification status
- How to validate
01 · Where the evidence stands
Two properties are physically verified. The application path is not.
The short version, in three lines. It is the same three lines wherever this state is summarized on this site, because they are rendered from one source.
- Device Authority: physically verified, on Android, one handset model
- A device identity is a P-256 key generated in the Android Keystore, non-exportable, hardware-backed where the platform allows, with attestation-chain verification. Bind, reconnect, reboot, rotate, revoke and post-revoke refusal were demonstrated on real hardware. The scope is one handset model, which makes it a demonstration rather than a device compatibility matrix. iOS and macOS carry their own evidence state, which Assurance sets out platform by platform.
- Human Authority: physically verified, at Command
- An operator authenticating with a physical hardware security key, producing a Command session that carries an authority role and is recorded in a verifying audit chain. It proves the operator step, and only that step. The device key, the organization root and every payload key sit outside its scope, as does any endpoint capability.
- Physical acceptance of the application path: outstanding
- Two-endpoint acceptance of the application path remains outstanding on every platform, reboot persistence awaits physical execution, and the duress gesture and its canary delivery are pending. This class of evidence is tracked separately from automated and controlled-environment verification, and it is not claimed until it exists. Independent external assessment remains open for every property on this page.
02 · How to read this page
Evidence states, not maturity levels.
A property moves up this scale by acquiring a different kind of evidence, not by becoming more important. Most of this system sits at VERIFIED. The distance between VERIFIED and PHYSICALLY VERIFIED is the distance between an automated result and a demonstration on real hardware, and this page keeps them apart.
DESIGNED
The architecture exists. Implementation evidence is not yet sufficient.
IMPLEMENTED
Production-intended code exists on the path the property describes.
VERIFIED
Automated and adversarial evidence supports the property. This is not physical endpoint verification.
PHYSICALLY VERIFIED
Demonstrated on real hardware, through the path the property describes, under controlled evidence conditions.
EXTERNALLY ASSESSED
Examined by an independent qualified third party. Nothing on this page has reached this state.
Physical two-endpoint acceptance of the application path, and the reboot persistence test, both remain outstanding. They are listed as their own rows rather than folded into a summary.
03 · Evidence by platform
Cross-platform product. Platform-specific evidence.
Tunnel Sovereign runs on Android, iOS and macOS, and the authority plane is integrated on all three. Physical evidence exists on one of them, for one property, on one handset model. Both of those sentences are true and neither substitutes for the other.
Android
IMPLEMENTED · Authority plane on the application's real send, file, voice-note, call, room and vault paths.
DEMONSTRATED · Automated and adversarial evidence, and an end-to-end run in a controlled development environment.
PHYSICAL · Device Authority only, on one handset model. The application path awaits physical evidence.
iOS
IMPLEMENTED · Authority plane integrated on the operator endpoint.
DEMONSTRATED · End-to-end run in a controlled development environment, on the iOS Simulator.
PHYSICAL · Open. Physical evidence for iOS remains to be established.
macOS
IMPLEMENTED · Authority plane integrated on the desktop endpoint, including Vault.
DEMONSTRATED · End-to-end run in a controlled development environment, on a local build.
PHYSICAL · Open. Physical evidence for macOS remains to be established.
A demonstration in a controlled development environment is evidence that the application behaves as described. It is a different class of evidence from physical acceptance, and this program keeps the two apart.
04 · Assurance register
Property by property, with the state and the limit together.
The limit column is not a footnote. A register whose limits are vague is a marketing table, so each row carries the boundary of its own evidence.
Device identity is hardware-backed and non-exportable
EVIDENCE · Real handset, attestation chain, bind / reboot / rotate / revoke
LIMIT · One handset model, on Android. Not a device compatibility matrix, and no equivalent on iOS or macOS.
LAST VERIFIED 2026-09
Operator authentication by physical security key
EVIDENCE · Hardware security key, server-side audit chain
LIMIT · Proves the operator step. Not a device key, not an organization root, not any payload key.
LAST VERIFIED 2026-09
Authority enforcement on the application's real paths
EVIDENCE · Automated, adversarial and structural
LIMIT · Physical two-endpoint acceptance is outstanding, on every platform.
LAST VERIFIED 2026-09
Directional and per-capability authority
EVIDENCE · Automated
LIMIT · A grant one way leaves the reverse leg unauthorized. Physical pending.
LAST VERIFIED 2026-09
Queued work is re-authorized before it moves
EVIDENCE · Automated and adversarial
LIMIT · Withdrawn authority stays withdrawn through a later grant. Physical pending.
LAST VERIFIED 2026-09
Secure Mission Bundle verifies through the authority chain
EVIDENCE · Engine conformance on hardware, frozen vectors
LIMIT · Engine-level. Not application-path physical verification.
LAST VERIFIED 2026-09
Governance receipts are signed and minimal
EVIDENCE · Automated and adversarial
LIMIT · The receipt signing key is software-protected in application-private storage. Device Authority uses a separate non-exportable hardware-backed key. Receipts are not hardware-attested.
LAST VERIFIED 2026-09
Federation between independent organizations
EVIDENCE · Automated, two live domains
LIMIT · Control plane. The endpoint path for federated traffic is not physically verified. Not a certified cross-domain solution.
LAST VERIFIED 2026-09
Duress persists before it takes effect, with no in-application undo
EVIDENCE · Automated and adversarial
LIMIT · The physical gesture and the canary delivery are pending verification. No wipe, destruction, concealment or decoy is performed, by design.
LAST VERIFIED 2026-09
Authority survives restart and reboot without resurrecting
EVIDENCE · Automated
LIMIT · Resists restart, reboot, clock rollback and provisioning replay. Not resistance after compromise of the platform's protected application storage.
LAST VERIFIED 2026-09
Reboot persistence demonstrated on handsets
LIMIT · Pending the physical acceptance procedure, which is tracked separately from automated and controlled-environment verification.
Two-endpoint acceptance of the application path
LIMIT · Outstanding on Android, iOS and macOS alike. This is the item that would move application-path properties from VERIFIED to PHYSICALLY VERIFIED.
Independent external assessment
LIMIT · Every suite behind this page was written by the implementation's own authors.
05 · Evidence
Reproducible results, and what each one proves.
Every figure below is reproducible on your own machine in under a minute. Each row states what the result demonstrates, where it stops, and when it was measured.
Every figure below is dated. These were measured between 2026-08-29 and 2026-09-04, against the baseline frozen for external assessment. A figure and the date it was taken move together, and a figure that cannot be dated is not published.
Application-path authority enforcement
APPLICATION PATH · AUTOMATED + ADVERSARIAL · MEASURED 2026-09-04
The current candidate's own suite: 202 tests discovered, 187 passed, 15 skipped, 0 failures, alongside 95 of 95 on the control plane. It exercises the authority decision on the application's real send, file, call, room and vault paths, including adversarial cases. The 15 skips are one integration class, EnrollmentProtocolTest, which runs only against an isolated live server stood up by its own driver script and refuses to run against a production host: enrollment-protocol coverage rather than authority coverage, skipped rather than counted as a pass.
WHERE IT STOPS · Automated and adversarial evidence on a host, not a demonstration on two handsets. Physical acceptance has not been performed. External assessment: not done.
Reference implementation suite
REFERENCE IMPLEMENTATION · MEASURED 2026-08-31
Ten test files covering the authorization object, its validation rules and its refusal branches.
WHERE IT STOPS · A suite written by the same authors as the implementation. Not an external review.
Independently implemented internal verifier, authorization vectors
INDEPENDENT-LANGUAGE VERIFICATION · MEASURED 2026-08-31
A verifier written separately, in a different language and against the specification rather than the code, parses and validates the authorization object and agrees on every assertion.
WHERE IT STOPS · Independent of the implementation code path. Built inside the company, so it is not an external assessment.
Cross-language conformance on physical hardware
ENGINE CONFORMANCE ON HARDWARE · MEASURED 2026-08-29
Kotlin and JavaScript implementations agree on a real handset, not only in a harness.
WHERE IT STOPS · One handset model. This measures the authority engine on hardware. It is not verification of the application path, which has not been demonstrated on handsets.
Wire vectors, independent cryptographic library
DETERMINISTIC VECTORS · MEASURED 2026-08-31
The wire format reproduces exactly under a different Ed25519 library, so it is not an artifact of one dependency.
WHERE IT STOPS · Format conformance. Not a cryptographic proof.
Relay exposure, measured
MEASURED ENUMERATION · MEASURED 2026-08-31
What the delivery infrastructure holds was enumerated by measurement: seven fields, carrying no direct sender, recipient or mission identifier.
WHERE IT STOPS · Aliases, ciphertext size and timing remain observable to any party carrying traffic, and correlation over time is not prevented.
Two implementations transcribed from one another agree with one another’s mistakes. These were written independently against shared vectors and reconciled only through them.
06 · Independent assurance
The assurance position, stated before you ask for it.
Internal testing is evidence. It is not certification, and this site keeps the two apart. Independent third-party assurance is the next step on the institutional deployment path, and its current state is listed here in full.
OPEN
Independent security evaluation
Every security property published here is currently asserted by its authors. An external evaluator has yet to examine them.
OPEN
Penetration assessment
Awaiting an independent assessor as part of the institutional deployment path.
OPEN
Cryptographic implementation review
The primitives are standards-track. The implementation awaits external review.
OPEN
Certification and accreditation
No scheme has been selected, and none is held. Entry into a pathway is funded work, not a claim.
OPEN
Government operating approval
None is held, and no classified-system approval is represented anywhere on this site.
GAP, QUANTIFIED
CNSA 2.0
The suite is ML-KEM-768 with Ed25519. National Security Systems require ML-KEM-1024 and ML-DSA-87, so a parameter migration is required.
OPEN
Reproducible builds and production signing
Identified internally as the highest-value outstanding security work.
UNDER REVIEW
Export-control classification
Referred for specialist review. No classification is asserted here.
07 · The assurance path
Where this sits, and what closing it requires.
Independent assurance is a stage on a path, not a box that was left unticked. The sequence below is the one this program is following. The stage it is at is marked, and the four after it are drawn as what they are: not yet done.
Internal verification
Automated, adversarial and cross-language evidence, plus live testing in a controlled environment. Substantially complete, and written by the implementation's own authors.
Application and physical acceptance
Two-endpoint acceptance of the application path on real hardware. Device and operator authority already carry physical evidence within a stated scope; the application path does not.
Independent security assessment
An external qualified party examining a frozen, reproducible baseline. Architecture, protocol, endpoint and infrastructure assurance are separate disciplines and are scoped separately.
Remediation and retesting
Findings are fixed and the affected properties are retested against the same baseline, so a result can be attributed to a version.
Deployment-specific certification
Certification or accreditation against the scheme a deployment actually requires. No scheme is selected, and none is held.
Current stage: controlled evaluation readiness and internal verification. Independent external assessment and deployment-specific certification remain planned assurance milestones.
08 · Delivery continuity, measured
What happens to queued material, behavior by behavior.
Measured on a Samsung SM-F971U running Android 17 in August 2026, without a battery exemption. An evaluator can reproduce this with a handset, so it is stated exactly.
VERIFIED
Queue persistence
Queued material survived every reboot cycle, ciphertext byte-identical.
VERIFIED
Device reboot
The application is started by the system for its own boot receiver, and outstanding work is re-enrolled with the application never opened.
VERIFIED
Delivery on operator relaunch
Work scheduled at startup executes and delivers.
NOT ESTABLISHED
Execution after secure unlock alone
After re-enrollment the worker did not execute: standby bucket 50, no worker entry in the platform scheduler. Delivery required an operator to open the application.
NOT ESTABLISHED
Automatic retry after transport restoration
With the transport restored and the device left alone, no delivery occurred across an eight-minute observation.
NOT ESTABLISHED
Recovery after process death
Terminating the background process did not produce autonomous recovery.
NOT MEASURED
Behavior under a managed-device policy
A managed deployment can grant the execution allowances a consumer handset withholds. This has not been measured.
The supported public statement is therefore narrow: queued material survives device restart, outstanding work is re-enrolled at boot, and delivery completes when an operator next opens Tunnel. Autonomous delivery without operator action is platform-policy dependent and is not claimed.
09 · Certification status
Certification status, in one line.
Tunnel Sovereign holds no certification, and this site publishes no certification mark, scheme listing or approval. A standards trajectory is a direction of travel rather than a certificate, and the two are kept apart here.
10 · Validate it yourself
The fastest way to test the central claim.
The relay exposure measurement takes seconds, requires no prior context, and renders the central architectural claim as data rather than as argument. It is the first thing we suggest a technical evaluator runs.
The full threat model, the security invariants register with falsification tests, the attack-tree compendium and the metadata exposure budget are available under a non-disclosure agreement in a working session with an engineer. See the Trust Center for the document index.
The same evidence state, in the shorter public document a reviewer can circulate: Download the Evaluation Brief (PDF, 12 pages).