Support and Security Update Policy

1. Scope

This policy applies to the AirNode ventilation controller, which consists of two separate assemblies with very different technical characteristics: the controller — it carries the firmware, the control logic, the local web interface, and all network connectivity; and the external sensor satellite — it measures outdoor temperature and humidity and reports them to the controller over a wired connection.

AirNode commits to providing security updates for the controller firmware of each individual device for five years from the date on which that device was purchased. The period runs per device and starts on the purchase date of that particular device as shown on the proof of purchase — not on a single end date for the whole product line. A device bought later is therefore supported for longer. What is not yet settled is how the start of the period is determined where no purchase date can be evidenced; that addition is still outstanding.

This commitment is a guaranteed minimum, not a ceiling. It states how long we supply security updates at the least. It does not state that your statutory rights end when it expires: your rights on the purchase of goods with digital elements — in particular the statutory update period owed under § 475b(4) of the German Civil Code — follow from the law and not from this policy. The statutory period is determined by the nature and purpose of the product and the circumstances of the individual case, and may in an individual case be longer than the one committed to here. This policy does not shorten it and cannot shorten it.

Covered is the firmware of the controller, including the local web interface embedded in it. The free cloud service is not the subject of this update commitment; section 6 applies to it separately.

1.1 The external sensor satellite — no field-update path

The sensor satellite cannot be updated remotely. This is not an operational choice but a property of the assembly, and we state it here explicitly rather than noting it elsewhere: the satellite can only be programmed with physical access to the opened device; there is no bootloader, and therefore no mechanism by which the satellite could accept new firmware. The satellite also has no network interface; it is connected over a wired link inside the customer’s installation and communicates only with the controller.

What this means for you: should a fault ever occur in the satellite that requires a firmware change, it can only be remedied by physical service on site — on the opened device, or by replacing the assembly. Updating it over the network, through the web interface, or through the cloud is technically impossible. How such a service case is handled and charged is not governed by this policy; what this policy deliberately does not promise here is a remote update.

Your statutory rights are unaffected by this. That this policy does not govern the service case does not mean you bear it: who bears the cost of such a remedy follows from the law in the individual case — in particular from the contract of sale for the hardware and the rights in respect of defects under §§ 434 ff. of the German Civil Code. Where the defect is security-relevant, a claim to a free remedy may already arise from that. The paragraph above describes only what is technically possible and says nothing about who pays.

Why the exposure is different: the controller is connected to your Wi-Fi and — if you enable it — to the internet; it accepts requests from the network and opens outbound connections. It is therefore reachable over the network and needs regular security updates. The satellite is not: it has no network connectivity and no service that could be addressed from a network. Attacking it would require physical access to the installation — the same precondition under which it is legitimately programmed. For this reason, this policy states the satellite’s position openly instead of claiming a remote update capability that does not exist.

Two points belong to a support commitment in this form — controller fully covered, satellite expressly named with its limitation: we state the limitation before purchase as well, not only in this policy (section 7), and we make no blanket statement that all firmware components are updated for the declared period. This classification would need to be reassessed if the satellite were to take on a safety-critical function in the future; today it measures only temperature and humidity and reports those values to the controller.

2. What a security update is

A security update within the meaning of this policy is a change to the controller firmware that removes a vulnerability — in our own code or in one of the third-party components we include — through which the confidentiality, integrity, or availability of the device, its configuration, or its measurement data could be impaired. This includes in particular vulnerabilities in network and TLS processing, in the authentication of the local web interface, in the update path itself, and in the libraries we include.

To be distinguished from these are feature updates — new functions, usability improvements, or changes to the control behaviour. Such updates may occur, but they are not the subject of this commitment. We reserve the right to deliver security fixes and functional changes in a single firmware release; for an embedded device this is the normal case.

This policy states no fixed release frequency and no guaranteed response time. A security update is produced when a vulnerability becomes known that affects the device; urgency depends on severity and on actual exploitability in the shipped configuration.

Reports of possible vulnerabilities can be sent to contact@air-node.net.

3.1 Locally over your own network

There are two mutually independent ways to get a firmware update onto the controller. They are listed in order of reachability, starting with the one that has the fewest prerequisites.

A firmware image can be handed to the device directly: via the device’s own operating interface within the same local network, authenticated with the device’s administrator access. The device writes the image straight into the firmware slot that is not currently running and restarts. This path requires neither the AirNode cloud service, nor third-party services, nor an internet connection — only a network route to the device on your own network and a firmware file you already have. It is therefore the path on which a multi-year update commitment can still rest even if third-party services or our own cloud service are unavailable.

A limitation we state openly: on a local upload, the device does not compare a checksum supplied by the caller. The local path is therefore expressly to be treated as an administrator operation. Integrity rests on the complete conclusion of the write and on signature verification at boot (section 3.3). Even so, upload only firmware files whose origin you know.

3.2 Via the cloud service

If the device is connected to the cloud service, an update can be triggered remotely. This path requires the entire chain to be reachable: the signed release, its ingestion into our platform service, its release for the device, an internet connection at the device, and the download. If any of these stations fails, the device either does not receive the trigger or cannot load the image — in that case the running image remains unchanged.

On a remote update, the device verifies the integrity of the downloaded image and aborts on any mismatch before the boot state is touched.

This policy makes no statement about the availability of the cloud service; no availability commitment is associated with it. What continues to work without the cloud service is set out in section 4; what applies if it is discontinued, in section 6.

3.3 Signing, two firmware slots, automatic return to the previous version

Both paths share the same on-device protection mechanism. The device holds two equally sized firmware slots (A/B). An update is always written to the slot that is not currently running; the running firmware remains fully intact until reboot.

Firmware images are signed; the device starts only firmware validly signed with our production key, and the shipped firmware is protected against readout and modification.

After an update, the new firmware must prove itself functional promptly; a missing connection to your home network expressly does not count as a failed start. If that proof does not arrive, the device restarts and returns to the previous firmware slot. A failed update therefore does not leave an unusable device.

4.1 Runs entirely on the device

The AirNode is built so that its actual job — ventilating when ventilating makes sense — continues without our cloud service and without an internet connection.

Running entirely on the device: indoor and outdoor sensor readings; the differential control logic — the decision whether the fan should run, taken from a comparison of absolute humidity indoors and outdoors, with hysteresis, a frost-protection limit, and a minimum dwell time in the current switching state; the weekly schedule, which requires a valid clock obtained from a configurable time server — not from the AirNode cloud service — and which stays idle without one while the control logic continues to run; manual fan control, settable locally at any time to off, automatic, or on; and the local web interface on the device, which is embedded in the firmware image, loads nothing from the internet, and — provided access-point operation has not been switched off — remains reachable over its own access point if there is no Wi-Fi connection.

None of the functions listed above depends on the device’s cloud client.

4.2 Does not work without the cloud service

Without the cloud service, the following do not work: access from outside your own network — without it, the device is reachable only on the local network; the cross-device overview of several devices in a single, account-linked view; long-term history — the device holds only a limited measurement archive covering the last hours and days, and anything beyond that takes place exclusively in the cloud service; and alerts and notifications by email or push, which are a platform service — the device itself sends no notifications whatsoever.

5. End of the support period

When the support period for a given device expires, security updates for that device end. What this does not mean: the device does not stop working. The firmware contains no expiry mechanism, no time lock, and no licence check — nothing that ends the device’s function after a cut-off date or for lack of activation. The last installed firmware keeps running, and with it all the functions listed in section 4.1.

For completeness: as long as a device is connected to the cloud service, the platform can send it commands — restart, setting the fan mode (including "permanently off"), changing the control parameters and the schedule. That is the ordinary remote control you switch on by pairing with the cloud service, and it ends as soon as the device is no longer paired or no longer connected to the internet. There is no command that renders a device permanently unusable. The local update path also stays open: the path in section 3.1 works regardless of whether we still publish updates (section 3.1).

What it does mean: from that point on, we no longer close newly discovered vulnerabilities for that device. We then recommend either replacing the device or operating it in such a way that it is not reachable from the internet.

What expiry likewise does not mean: your statutory rights do not end with it. The support period describes how long we supply security updates. It is not a limitation period for your rights in respect of defects and does not limit them. Whether updates were owed beyond that period in an individual case follows from the law (section 1) and may differ from the duration committed to here.

We will not let the support period lapse silently but will announce it — through all three of the following channels, so that the announcement also reaches those who run the device purely locally without a user account: on the website under Support, naming the purchase periods affected; in the device’s local web interface — the channel that works without an account and without a cloud connection; and by email, insofar as a user account exists and an address is held there. Email alone expressly does not suffice: under section 4.1 the AirNode is fully usable without an account, and anyone who never created one has given us no address. The notice in the local web interface presupposes that you open it; we cannot promise that every announcement actually reaches every user.

The end of the support period is not the same as a discontinuation of the cloud service. The cloud service may continue beyond it; if it is discontinued, section 6 applies.

6. Discontinuation of the free cloud service

The cloud service is intended for the support period stated in this policy. Should a discontinuation become necessary, it will follow the transitional provisions below.

If a discontinuation occurs, the following applies: announcement at least six months in advance, by email to the address held in the account — and, because a device can also be operated entirely without a user account, additionally through the two account-independent channels from section 5 (the website and the device’s local web interface); data export throughout the entire notice period — the data you have stored in the cloud remains exportable until the shutdown date; and a closing firmware release that leaves local operation of the device intact. After the shutdown, the device is intended to keep doing exactly what section 4.1 describes. That closing firmware release is a technical safeguard for the exceptional case; it applies on its own terms, independently of whether the cloud service continues as the first sentence of this section states it is intended to.

7. Communication at the point of sale

So that the commitment in section 1 is visible before purchase rather than only afterwards: the committed support period is stated before the purchase is concluded — in the product description and by a reference to this policy in its published version. The limitation regarding the sensor satellite in section 1.1 is stated in the same place and with the same prominence as the commitment itself; it does not appear solely in this policy. The end date follows from the purchase date of the individual device as shown on the proof of purchase; the proof of purchase is therefore the authoritative evidence for the start of the period. What governs a device is the version of this policy that was published at the time of its purchase. Later versions cannot worsen the commitment for devices already sold. Earlier versions remain traceable through the version history.

8. Version history

Version 1.0, 2026-07-27: First binding version.

Version 1.1, 2026-08-08: Section 6 — continuation of the cloud service stated as an intention rather than a commitment; section 1.1 — note that statutory rights are unaffected.