Security & CVD

1. Security model

One-Home is designed as a hybrid local-first platform. Home logic remains local where possible, while One-Home Cloud provides features that benefit from central delivery. This limits the impact of an internet outage and reduces the amount of home data that needs to go to the cloud by default.

2. Technical security principles

The current architecture includes or provides for the following measures, among others:

• a unique installation identity with a cryptographic device key;
• signed device requests with timestamp/nonce checks to make replay attacks more difficult;
• separate signing for licence/entitlement information and release data;
• secure browser/account sessions with CSRF protection;
• 2FA for sensitive administrative functions;
• locally encrypted cloud backups before their contents are uploaded;
• time-bound, explicit consent for supported remote diagnostics;
• audit information for relevant administrative and update actions.

The specific implementation may change between releases. Security claims on this page are therefore architectural/product claims, not a guarantee that the software is completely immune to vulnerabilities.

3. Updates and the software supply chain

Official updates should be offered with integrity checks and signed release information. The updater is designed to build/start a new version first, perform health checks and, where possible, roll back if the new installation fails to become healthy.

For production, dependency monitoring, SBOM/dependency inventories, secrets management, controlled build/release procedures and periodic security testing should form part of the maintenance process.

4. Backup and recovery security

Cloud backups are designed to be encrypted locally before upload. Recovery keys and local secrets must be kept out of public repositories, logs and support tickets. Recovery procedures should be tested regularly.

An encrypted backup is only useful when both the backup and the necessary recovery information are available. Store recovery information separately and securely.

5. Coordinated Vulnerability Disclosure — scope

We invite security researchers to report technical vulnerabilities responsibly. The following components are generally in scope when they are demonstrably managed by One-Home:

• one-home.online and official One-Home subdomains;
• My One-Home and the official Admin Portal;
• One-Home Cloud APIs;
• official One-Home Core release packages published by One-Home.

Third-party services, hardware, accounts and infrastructure are not automatically in scope. Do not test systems unless you can reasonably establish that they are managed by One-Home.

6. Rules for responsible research

When carrying out security research, we ask you to:

• use only your own account, installation or an explicitly authorised test environment;
• go no further than necessary to demonstrate the existence and impact of a vulnerability;
• not download, alter, delete or publish other people's personal data;
• not carry out denial-of-service attacks, mass scanning, spam, social engineering or physical attacks;
• not make passwords, tokens, private keys, recovery keys or other secrets public;
• first report the vulnerability to One-Home confidentially and allow reasonable time for investigation and remediation;
• store evidence securely and delete it after completion when it is no longer needed.

7. How do you report a vulnerability?

During early access, use the contact option at one-home.online and start the first line of your message with SECURITY. Do not include passwords, private keys, recovery keys or large datasets in your initial message. We can then agree on a suitable secure channel if sensitive technical details are needed.

A good report includes:

• the affected domain, endpoint, release or component;
• a clear description of the vulnerability and its expected impact;
• minimal steps to reproduce it or a proof of concept;
• any relevant request/response information, with secrets carefully removed;
• a secure way for us to contact you.

8. What can you expect from us?

We aim to acknowledge a serious security report within 5 working days and then provide periodic updates while the investigation is ongoing. The actual resolution time depends on severity, complexity, required dependencies and the ability to test safely.

We ask researchers to coordinate publication until a reasonable remediation period has elapsed. Any public recognition or reward is not automatic and will only be offered if separately agreed.

9. Research in good faith

If you reasonably comply with this policy, act in good faith and try to prevent harm, our intention is to treat your report as responsible security research rather than misuse of our reporting procedure. This is not a general legal safe harbour and cannot override third-party rights or mandatory law.

10. Out of scope

Examples that are not normally treated as security vulnerabilities include missing security headers without demonstrable impact, self-XSS without a realistic attack chain, clickjacking on pages without sensitive actions, purely theoretical issues without reproducible impact, rate-limit reports that can only be demonstrated with unrealistic traffic, and issues in third-party products that One-Home does not manage.

If you are unsure whether something is in scope, report it with minimal information rather than actively continuing to test other people's data or systems.

11. Security incidents

An operational security process should include procedures for detection, triage, containment, recovery, logging and communication. When an incident affects personal data, the reporting or notification obligations under the GDPR or other applicable law will be assessed.

12. Production hardening

For a commercial production release, the recommended release criteria include independent security review/penetration testing, dependency and secrets scanning, secure key rotation, database hardening, restore tests, monitoring and a documented incident response process.

13. Security contact and security.txt

The standard file /.well-known/security.txt refers to this policy. Before the broad public/commercial launch, a dedicated secure security contact will also be established, such as a monitored security email address and, optionally, an encryption key.