Security and update policy for ewusOS and every EWUS gateway.
Trust, with the
working shown.
How the gateway is secured, how updates reach it, what we commit to in writing, and how to reach us if you find something wrong.
Security decisions we made before writing the product.
Every instruction is verified
The gateway verifies the signature on every instruction it receives before applying it, including instructions that appear to come from our own cloud. Anything that does not verify is rejected.
Hardened by default
No default passwords. Credentials unique per device. Management traffic separated from user traffic, and no external administration exposed by default.
Updates that can undo themselves
We intend to build ewusOS around a second-image update scheme with automatic rollback, so a failed update would return the device to its last good configuration instead of leaving it offline. This isn't built yet. The underlying partition layout and rollback-trigger design haven't been finalized.
Failure keeps you connected
If our software has a problem, your connectivity is not what we take away. Protection that can put you offline is a liability, not a safeguard.
Update policy
Ten years of security updates. Five years of new features.
Security and protection updates for ten years from a device's launch, and new features for at least five. Updates are designed to arrive over the air, on a dual-image scheme with automatic rollback, once that update pipeline is built. If the company ever ceases to operate, the firmware source is published so that every device already sold stays maintainable by someone else.
Wording pending legal sign-off. These durations are what our internal decision register states. The exact contractual phrasing, and the mechanism behind the source-release commitment, are with legal counsel, and this page will be updated to match whatever they settle on.
Found something? Tell us before you tell the internet.
If you believe you have found a security issue in an EWUS device, in ewusOS, or in any EWUS service, write to us with enough detail to reproduce it. We will confirm we received it, tell you what we find, and credit you if you want the credit.
A dedicated security address and a published policy
A vulnerability report should not go to a general contact address, and a disclosure policy should state response times and a safe-harbour position. Neither exists yet, so this page names the gap rather than implying a process that is not running. Until it does, the address above reaches a person.
The rest of the paperwork.
What we promise, what we collect, and the terms behind both.