We are not asking for your trust, we are showing you the design — on each of the three segments: the module in the wall, the gateway in the building, the platform. And we tell you where your building's data is designed to go: it stays in the building, not with us.
Product in development. The complete Mentivira solution will be available in 2028.
A building automation system commands relays that start pumps, open gates and cut circuits. The primary risk is not that somebody learns what temperature you keep the hallway at. The risk is that an outsider sends a command the building then executes, or that usage data ends up somewhere you did not choose.
That is why we treat security as three separate segments, each with its own threat model: module to gateway (an attacker with an antenna, out in the street), the gateway itself (an attacker holding the device, after a theft), and the platform (an attacker who reaches our infrastructure).
Every mechanism below has a single justification: what exactly becomes impossible because it exists. Where something is designed and tested but not yet certified, we say so plainly.
01Module
Segment 1 — from the module in the wall to the gateway in the building, over our own 868 MHz radio.
Each module will have its own key pair, generated and kept on the chip, which never leaves it. The protocol has no symmetric key shared across the fleet, so there is no single secret that — extracted from one cheap module bought anywhere — would open every Mentivira installation. Compromising one module stays the compromise of that one module.
At every power-up, module and gateway negotiate fresh session keys through a Noise_KK handshake, in which each side already knows the other's public key. The consequence: anyone obtaining one session's keys cannot read earlier or later sessions, and an unknown gateway has nothing to open the conversation with.
Every frame is encrypted and authenticated with AES-256-CCM. Authenticated means more than hidden: a frame altered in transit, even by a single bit, is rejected, not executed. Nobody can turn "switch the light off" into "start the pump".
A valid frame captured off the air and resent later does not work. Session counters live in volatile memory, and a restart leads to a new session, not to a resumption of the old one. Someone who records the gate-opening command today cannot replay it tomorrow.
A module will join an installation only if somebody physically held the device: the claim code will be on the equipment, and adding it will happen inside a commissioning window that is opened explicitly, with two-step confirmation. A neighbour's device will not be able to "join" your installation, even if it hears your radio.
The protocol has the module accept only an enrollment offer cryptographically signed by the platform, and the gateway accept only a module whose identity checks out against the factory database. So an impostor gateway will not be able to steal modules from your building, and an impostor module will not be able to join the installation.
Security is not a layer added at the end, it is designed into every link. Below, what is designed to protect each segment and what connects them.
What we verified ourselves, on a test bench and on a test installation in a real home. These are not customer-site measurements: the product is not yet commercially launched.
02Gateway
Segment 2 — the device installed in your building. Here the threat model includes an attacker who physically holds the equipment.
The gateway's system will be a single signed image, mounted read-only and cryptographically verified at every boot. If anybody alters a single file, the device will not boot with it. That rules out the "somebody got in, left something extra behind, and nobody noticed" scenario.
Nothing will be installed or compiled on the gateway — the image has no package manager. Any software change will arrive as a new signed image, installed A/B: if the new version fails its health checks, the device will automatically roll back to the previous one. A failed update will not leave you without a system.
The building's data will sit on an encrypted partition whose key is sealed inside the board's Trusted Platform Module (TPM) and only unseals if the device booted the signed software. Pull the disk out and put it in another computer: unusable content. Stealing the gateway would not be a data breach.
When the device leaves service or moves to another customer, we will not delete files — we will destroy the key. The data physically remains on the disk, but without the key it is noise. This is the only form of erasure that does not depend on trusting whoever ran the procedure.
The gateway is designed to open a single outbound channel, encrypted with mutual TLS against a private certificate authority, and to deny any other egress by default. There will be no inbound port from the internet: nobody outside will be able to initiate a connection into your building. The only listening port will be on the local network, for the app — and the app will pin the gateway's certificate fingerprint, so not even on the local network can an impostor fool you.
We will not hold standing access into your building. When an intervention is needed, the gateway itself will open a reverse tunnel for one specific session, and that session will be recorded in full. Access will end when the session closes, not when somebody remembers to close it.
03Platform
Segment 3 — the platform. Building telemetry will not reach it (see the next section), but accounts, configuration and service records will. Those need their own guardrails.
Separation between partners and between end customers will not be only a condition written in application code, but also a policy enforced by the database on every row (Row-Level Security, RLS), applied mandatorily. The two layers are independent: a programming mistake in one query will not leak another building's data, because the second layer stops it.
The user session will be a token signed by the identity service and then encrypted; every service will verify its signature against the issuer's public key. A forged or altered token will be rejected at the door. In the browser, the session will travel in a cookie that page scripts cannot read.
Access will be granted by role and reach down to the individual device, rather than stopping at the building. Guest access — the electrician, cleaning staff, a short-term tenant — will be time-limited and revoke itself on expiry, without depending on anybody's memory.
Each service will keep an audit log: what changed, by whom and when. This is the mechanism by which a question like "who changed the heating schedule on floor 2?" will have an answer, rather than a guess.
The platform will run on infrastructure inside the European Union, operated by a Romanian company. The architecture provides for no transfer of data to another continent, because it contains no component that would send it there.
Building telemetry — every temperature reading, every relay switch, every occupancy event — will be written and kept on the gateway in your building. The platform will not receive it. Not "will not look at it": will not have it.
The difference matters, practically and legally. A privacy policy changes with an email and a notice nobody reads. An architecture in which the data simply does not travel cannot change without redesigning the product and shipping a visible update. That is why we state it as an architectural property, not a commercial promise.
What will travel up to the platform is only what the service needs in order to exist: device health, update confirmations, the configuration you edit in the app, account administration events and service records. All of it over a single encrypted channel, opened from the inside outwards.
The encryption key will stay with the customer. The data partition's key will be sealed in your gateway's TPM, not held by us. The recovery key will be kept in escrow under dual control and will not be used without the customer taking part. Every building will have its own cryptographic domain — there will be no manufacturer key that unlocks everything.
The data is yours and it will leave when you decide. The gateway will expose a local API through which telemetry, history and events export in an open format into whatever reporting system you already use: energy accounting, an existing building management system, your own dashboard. We will not hold you captive in a format only we can read.
The consequence is worth stating bluntly: if our platform were compromised, the attacker would not find your building's history, because by design it is not there. And if the internet link drops, the history is designed to keep being written, locally, and the automations to keep running.
Our compliance target: the cybersecurity requirement of the Radio Equipment Directive (RED, Art. 3.3 of Directive 2014/53/EU), through the EN 18031-1 and EN 18031-2 standards, backed by a written security dossier — threat model, protection mechanisms, an item-by-item conformity matrix. This is a compliance objective in progress, with testing at an external accredited laboratory: we do not claim a certification already obtained. The second set of duties comes from Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA), which imposes firm deadlines on the manufacturer. Why this matters inside your building: these obligations do not depend on a supplier's goodwill or on your negotiating power — they are the manufacturer's, by law, for the whole support period.
| Obligation | Deadline | What it means for your building |
|---|---|---|
| Reporting an actively exploited vulnerability — initial notification | 24 hours | A vulnerability exploited in the wild cannot be kept in a drawer: the authority, and therefore the market, learns of it on day one. |
| Detailed notification | 72 hours | The technical description and mitigations are communicated within three days, not at the end of the analysis. |
| Final report | 14 days | Root cause, fix and preventive measure are documented — not a topic that quietly fades. |
| Minimum security support period | 5 years from placing on the market | Security updates do not stop because the model left the catalogue. |
| Updates kept available | 10 years | A device installed today can still be brought up to date a decade later. |
| Software bill of materials (SBOM) and vulnerability scanning | at every image build | We know exactly what runs on the device in your building, so the response to a new vulnerability is measured in days, not months. |
| Fast lane for critical vulnerabilities | ≤ 7 days (our own design commitment, not a legal requirement) | A critical fix will reach the device on a path separate from the ordinary update calendar. |
The gateway will be bound at commissioning to the holder of the installation and serve a single dwelling. In a block of 40 apartments there will be 40 separate data domains, not one that somebody administers on everyone's behalf. This is a design requirement, not a setting that can be changed on request.
The consequence is twofold. One apartment's data will never end up in the same pile as the neighbour's, and the building manager will not unwittingly become a controller of residents' personal data — a legal position they never asked for and cannot realistically manage.
For account data the strategy will be anonymisation-first: consumption series can be retained while the link to the person is severed permanently and irreversibly. Deletion will come in two modes — irreversible anonymisation, which keeps the statistical value without the person, and full deletion of the account and its associated data. Personal data exports will be provided in an open format, on request.
Recordings of technician intervention sessions will be kept for a limited period, as evidence of what was done in the building, and deleted when the retention period expires.
We do not claim patents. We hold no granted patents on this solution and we do not invoke patent protection as a selling point.
Certifications are in progress, not obtained. CE marking and conformity with the cybersecurity requirement of RED Art. 3.3, via EN 18031-1 and EN 18031-2, are compliance objectives, with testing at an external accredited laboratory. When we obtain certification, we will show it; until then we do not assert it.
An independent external security audit is planned, not completed. What exists today is the written security specification, the implementation and our own tests, including on real silicon.
The wired RS485 bus — the alternative to radio where cable is preferred — is designed to operate in plaintext, as a closed, physically controlled bus. This is a deliberate cost and firmware-simplicity decision: there, security comes from physical control of the cable route, not from encryption. Radio frames are encrypted and authenticated; wired-bus frames are not.
The product is not commercially launched. We have no commercial customers, and the figures marked as measured come from our own laboratory and field tests, not from installations in service. The complete Mentivira solution will be available in 2028.
The complete Mentivira solution will be available in 2028. Leave an address and you get a single e-mail, at launch.
No marketing, no sold lists. One e-mail, at launch.
The address is used only to notify you at launch, by ZYONARA SRL. You can withdraw it at any time by writing to [email protected]. Details in the privacy policy.