Quick answer: In 2026 Iris Information Technology moved its flagship digital intercom line from a proprietary real-time operating system to an embedded Linux platform. The trigger was not cost — it was the firmware support window. A proprietary RTOS ties security patches to one vendor's development queue; a Linux base lets us inherit upstream kernel and OpenSSL fixes. This article explains the decision, the trade-offs we accepted, and what it means for integrators specifying the line today.
Why we rebuilt the platform rather than the product
The hardware did not change much. The 10.1-inch LAN management centre unit, the 7-inch digital colour video substation and the 10.3-inch digital colour video substation kept their panel sizes, camera modules and mounting geometry. What changed underneath was the operating system.
That is a deliberately expensive decision. Rewriting a firmware stack invalidates accumulated hardware-specific tuning, breaks the tooling the factory test line depends on, and forces every field-update path to be re-validated. We took it because three pressures converged at once.
Pressure one: the support window became a tender requirement
Buyers increasingly ask one question in writing: how long will you patch this device? Under the EU Cyber Resilience Act, which entered into force on 10 December 2024, manufacturers of products with digital elements placed on the EU market must address vulnerabilities through security updates and declare a support period.[1] The European Commission's own guidance confirms the main obligations apply from 11 December 2027, with the reporting obligations landing earlier, on 11 September 2026.[2]
Equipment specified in 2026 will be installed and operating inside that regulated window. A vendor that cannot answer the support-period question in writing is now a tender risk.
Pressure two: the patch pipeline was the bottleneck
On a proprietary RTOS, a critical vulnerability in a TLS implementation or a media-parsing library has to be fixed by the small team that owns the stack. On a Linux base, the same class of fix arrives from the upstream community, and our work becomes porting, testing and shipping rather than authoring the fix from first principles.
The difference is not theoretical. A patch that would have taken one developer two to three weeks of dedicated work in a proprietary stack becomes a matter of days when the fix already exists upstream and only needs integration testing against our application layer. That maths assumes the fix exists upstream at all — and for widely deployed open-source libraries, the probability is high, because the reporting and remediation process is public and continuous rather than vendor-gated.[3]
Pressure three: integrators wanted standard interfaces
A closed stack makes integration a negotiation. An open one makes it an engineering task. SIP call signalling, standard media codecs and documented HTTP APIs are what distributors ask for, because their clients already own the systems the intercom has to feed into.
What we gained
- Faster security patching. Upstream kernel and TLS fixes can be integrated and shipped on a predictable cadence.
- A stated support period. We can commit to a minimum five-year security-patch window from last manufacture, with a published end-of-support date per model.
- Standard interfaces. SIP for call signalling and documented HTTP APIs, so one call can be routed to a PBX, a softphone or a third-party indoor unit.
- Cleaner separation of layers. The application layer can stay stable while the platform underneath is updated and re-qualified.
What we gave up
This is the part vendors usually omit, and it is the part a specification engineer needs.
Boot time and memory footprint
An RTOS boots in a fraction of the time and fits in a smaller memory envelope. A Linux system needs a bootloader, a kernel and a user space, and consequently more flash and RAM for equivalent application behaviour. We absorbed that in BOM cost and board layout rather than passing it on as a slower user experience — but it is a real cost.
Determinism
Hard real-time response is harder to guarantee on a general-purpose kernel. Intercom is a forgiving workload in this respect: audio and video streaming tolerate tens of milliseconds of jitter, and the genuinely time-critical path is the door strike, which is driven by a dedicated output rather than by the application processor. So the loss is real but bounded. On a robotics or industrial-safety product it would not be an acceptable trade.
Standards compliance is not interworking
This is the gap most often missed. SIP interoperability became possible with the move, but RFC 3261 defines the signalling that makes intercom-to-PBX routing possible — it does not standardise door release semantics, hardware-accelerated video codec negotiation, or multi-apartment addressing.[5] Those remain per-integration work. Moving to Linux removed a platform obstacle; it did not remove the profiling work.
A larger attack surface
A general-purpose kernel and a user space with a package ecosystem present more potential entry points than a minimal RTOS. This is a genuine cost, and it is managed rather than eliminated: a signed firmware image, a disabled-by-default service set, no shell exposure on the production image, and a documented update channel. The OWASP Internet of Things Top 10 puts insecure ecosystem interfaces and the absence of a secure update mechanism among the most common weaknesses in connected devices, which is the specific risk set this control has to address.[4] It has to be an active commitment, not a one-off hardening pass at launch.
What changed for product line 01
The Linux digital intercom system line is the direct beneficiary. Concretely, the three units our distributors order most:
- 10.1-inch LAN management centre unit — call routing, apartment address mapping, event logging and door-release override for larger buildings.
- 7-inch digital colour video substation — the workhorse indoor monitor for standard residential units.
- 10.3-inch digital colour video substation — specified where the monitor doubles as a building-services panel or where residents need a larger image.
The level of detail in the existing architecture documentation still applies, because the topology did not change — see how a building video intercom system works for component roles and call flow.
Implications for the other product lines
Moving one line does not mean the others follow immediately, and distributors should not assume they will.
- Two-wire intercom. The two-wire line serves a different job: retrofit into existing cabling. Its firmware roadmap is separate, and its constraint is the cable, not the processor.
- Analogue intercom. The analogue door station line stays in the catalogue for cost-driven and legacy-replacement projects. There is no commercial case for moving a device whose buyer is optimising for unit price.
- Access control. The access control line already shares a credential database with the intercom layer, and benefits from the same API direction, but is on its own schedule.
How to evaluate the claim
Do not take a platform migration on trust. Four things are checkable before you commit to a project:
- Ask for the firmware support statement in writing, with model names and end-of-support dates. A verbal "five years" is not a tender document.
- Request the update mechanism. Is it signed? Can it be applied remotely, or does it need physical access? Remote update capability materially changes the lifetime cost of a 200-unit building.
- Test the SIP path yourself on your own PBX, with your own extension plan. Interoperability promises are cheap; a bench test is not.
- Check the security posture: which services are exposed by default on a production image, and what the device does on first boot with no configuration.
Frequently asked questions
Does the Linux platform mean the intercom can be hacked like a PC?
No. It is an embedded Linux image, not a general-purpose computer: a fixed service set, no shell exposed on the production build, and a signed firmware image. It is a smaller attack surface than a desktop, but a larger one than a minimal RTOS — which is why the update channel is the control that matters.
Will existing installations need replacing?
No. The platform change applies to the current Linux line from its introduction. Previously supplied units continue on their own support track, and we publish the end-of-support date for each model.
Is five years the guaranteed maximum, or can it be extended?
Five years from last manufacture is the committed minimum. Longer support is offered per project for larger deployments, and the agreed period is documented in the order paperwork.
Does the Linux line work with our access control system?
With our own controllers, yes, via a shared credential database. With a third-party panel, it depends on that panel's API — the wiring and design considerations are covered in our access control integration guide.
Where can we see the line demonstrated?
We showed the shipping firmware at ISE 2026; the write-up of the questions raised there is in our ISE 2026 recap. For a project-specific evaluation, contact us with your unit count, riser topology and cable type.
The honest summary
We traded boot speed, real-time determinism, memory footprint and a smaller attack surface for a support window we can put in writing, a patch pipeline that runs at upstream speed, and interfaces our integrators can design around without asking permission. For a building intercom product sold into a market that is about to regulate software support, that is the right trade. For an industrial control product, it would not be — and any vendor telling you one platform choice is right for every device is selling a story rather than an engineering position.
If you are specifying the line for a project, our company profile covers the manufacturing base and qualifications behind it.
References
- EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act), entered into force 10 December 2024 — obligations covering security updates and a declared support period for products with digital elements.
- European Commission, "Cyber Resilience Act", DG CONNECT policy page — main obligations apply from 11 December 2027; vulnerability and incident reporting obligations from 11 September 2026.
- CISA, Known Exploited Vulnerabilities Catalog — the authoritative, continuously updated list of vulnerabilities with confirmed in-the-wild exploitation, maintained by the US Cybersecurity and Infrastructure Security Agency.
- OWASP, OWASP Internet of Things Project — the IoT Top 10 risk list, including insecure ecosystem interfaces and lack of a secure update mechanism.
- IETF, RFC 3261 — SIP: Session Initiation Protocol, June 2002.