Security policy

Nativa is a building-management and security hub sold as an appliance. We treat every vulnerability report as a product defect with a deadline, and we publish what we fix.

Reporting a vulnerability

Email [email protected].
Encrypt reports that contain exploit details with our PGP key: pubkey.asc
fingerprint 1840 0B27 43A9 4803 5B92 1AF7 3B42 3BA1 9713 3651 (valid until 2028-09-15).
Every hub serves the same contact at https://<hub>/.well-known/security.txt (RFC 9116), as does this site.
Do not open a public issue for a security problem.

Include: affected component and version, steps to reproduce, impact as you understand it, and whether you know of the issue being exploited.

What to expect

Step	Target
Acknowledgement	2 business days
Triage and severity (CVSS v4 + product impact)	7 days
Fix for Critical/High on `stable`	30 days, sooner if exploited
Fix for Medium/Low	next scheduled release, at most 90 days
Public advisory	with the fix, or after 90 days if a fix is delayed

Supported versions

Hub firmware, the mobile app, the Python worker tier and the vendored third-party components (Frigate, go2rtc, tailscale) are supported for 5 years from the date a hardware variant is first placed on the market, with security updates delivered free of charge for that whole period.

Component	Supported
Hub firmware, `stable` channel	latest release and the previous minor
Hub firmware, `beta` channel	latest release only
Mobile app	latest store release
Development snapshots	not supported

Safe harbour

Good-faith security research on your own Nativa hub, or on a hub whose owner has authorised you, is welcome. We will not pursue legal action for research that stays within these limits: no access to data that is not yours, no service degradation of hubs you do not own, no social engineering of our staff or customers, and a report to us before any public disclosure. Testing against our hosted coordinator or release infrastructure needs written permission first.

Scope

In scope: hub firmware (nativad, nativa-mediad, workers, admin UI, API), the mobile app and its hub transport, the update pipeline and its signing, the remote-access enrolment path, backup/restore.

Out of scope: third-party devices the hub talks to (cameras, Modbus/BACnet equipment, Shelly, YoLink), unless the hub mishandles their input. Report those to their vendor; tell us too if the hub's handling made it worse.

Full procedure, including our obligations under the EU Cyber Resilience Act: docs/security/vulnerability-handling.md in the product repository.