On 11 September 2026 a European regulation starts a stopwatch on camera vendors, and the trigger that starts it is stranger than the deadline it sets.
The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024, and most of it does not apply until 11 December 2027. Two parts arrive early: Chapter IV, on the notification of conformity assessment bodies, applied from 11 June 2026, and the reporting obligations in Article 14 apply from 11 September 2026. The second one is the one that reaches a person working alone. The European Commission's page on the reporting obligations opens with a sentence that leaves little room: "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements".
The windows are tight. From the same page: "They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours". A final report follows, no later than fourteen days after a corrective measure is available for an actively exploited vulnerability, and within a month for a severe incident. Everything goes to the national Computer Security Incident Response Team and to ENISA through one platform, which the Commission says "will be operational by 11 September 2026".
I build an Android app that runs a spare phone as a camera. I read this the way anyone with a product on a European store ought to read it, and I came out with a conclusion I had not gone looking for: the duty is easiest to discharge for exactly the architecture I spend most of my time arguing against.
The part small developers assume does not reach them
Two definitions in the Commission's summary of the legislative text do most of the work here, and neither contains the escape hatch a one-person shop expects to find.
A manufacturer, in this regulation, is a person who develops products with digital elements and markets them under their own name, "whether for payment, monetisation or free of charge". Free is not an exemption. A side project with an EU install base and no revenue sits inside the definition; the price was never the test.
And a product with digital elements is "A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". That second clause is where two camera companies with near-identical marketing copy stop resembling each other.
The regulated object is not where the icon is
Remote data processing has its own definition: "Data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions".
That is a functional test rather than an ownership one. If a camera app cannot show you your own hallway without a relay in the middle, the relay is not a separate service the vendor happens to also operate. Remove it and a function of the product stops working, which is precisely the condition the definition describes.
So for a relay-based camera the regulated object is an app, a handset, a fleet of servers, an account system, and every session that crosses between them. For a camera whose video never leaves the building, the regulated object stops at the edge of the phone.
Two products, two very different perimeters, and until now no rule obliged either vendor to say which one they were selling.
The four words the whole thing turns on
Here is the sentence I keep returning to. On the manufacturer's duties, the summary says: "the manufacturer is required to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product that it becomes aware of".
That it becomes aware of.
The clock does not start when exploitation begins. It starts when the manufacturer finds out. Which makes the reporting record a measure of how much a vendor can see, and only indirectly a measure of how safe the product is.
There are four ways a vendor learns that something is being exploited in the field.
The first is telemetry the vendor built. The product reports on itself: crash traces, session metadata, anomaly counters, the ordinary exhaust of software that talks to its author.
The second is infrastructure. The vendor watches their own machines and notices a shape that should not be there. Authentication attempts arriving in a burst from one address range. A device requesting streams that belong to a different household.
The third is that somebody tells you. A researcher, a customer, a CSIRT, a reporter with a deadline and a screenshot.
The fourth is the one I nearly left out of this article, and leaving it out would have flattered me. Every app on Google Play gets crash and ANR reporting whether or not its developer builds any, and the Play Console documentation is plain about where it comes from: reports arrive "when an app crashes or is not responding on an Android-powered device whose user has opted in to automatically share their usage and diagnostics data". I did not implement that and I cannot switch it off. It is a real channel and I have it.
It is also a narrow one, in three ways that matter for this regulation. It reports crashes, not exploitation, and the overlap between those two sets is real but partial — plenty of memory-corruption bugs announce themselves as a stack trace, and plenty of successful attacks never crash anything. It covers only the opted-in subset of devices, so it is a sample of unknown size rather than a census. And it is aggregated and dated for product quality: Android vitals updates daily and Google Play "will generally consider the last 28 days of data", which is a sensible window for judging an app's stability and a poor one for a duty measured in twenty-four hours.
So a vendor running a relay has all four, and the first three are theirs, built for the purpose, and pointed at exactly the events the CRA asks about. A vendor whose product never contacts them has the third, plus a fourth that belongs to the app store, was designed to answer a different question, and would tell me an unusual number of my installs started crashing on Tuesday — which is a hint worth having and is not a report of an actively exploited vulnerability.
Which is a cost, and it is mine
I have argued more than once that a camera whose video never leaves your own network is a better arrangement than one that streams through a company's infrastructure, and I still think so, for the reasons I usually give. This is the invoice for that position, and I would rather hand it over myself than have it presented later.
Software that does not phone home cannot tell its author it is under attack. If someone worked out tomorrow how to reach a large number of these installations, the most I would see is whatever fraction of it made the app fall over on a device whose owner had opted into diagnostics, arriving in a dashboard that averages the last twenty-eight days. An attack that works cleanly does not crash anything, and nothing else on my side is collecting the numbers a chart of it would be drawn from. I find out when a person emails me. My twenty-four hours begin at that email and not one second earlier, and the interval between the first exploitation and that email is invisible to everyone, me included.
That is not something I can engineer away without turning into the other kind of company. Visibility and privacy are opposite ends of one wire. Pulling on either end shortens the other.
What the trade actually buys
The honest version is not that local-only is safer in some general way. It is that local-only has a smaller and differently shaped set of things that can go wrong.
A severe incident on a centralised camera platform is, by construction, one event with a large blast radius. One key, one storage bucket, one authentication check written the wrong way round, and the number of affected households is a property of the vendor's customer count rather than of anybody's home network. That is the failure that produces the news story, and producing it requires the vendor to have first built a place where everyone's video converges.
A product that never aggregates anything has no equivalent single point. Whatever goes wrong goes wrong one installation at a time: worse for the household it happens to, and much better for the population.
So from September the regime will generate two kinds of record, and on paper they will look alike. Vendors with visibility will file reports. Vendors without it will file nothing.
What I do not know
I do not know how the phrase severe incident is meant to read for a product with no service standing behind it. The concept is written for something operational, and software running entirely on hardware belonging to somebody else does not obviously have incidents in that sense. It has vulnerabilities, and the two are given separate deadlines in the text, which suggests the drafters had different things in mind for each.
I am also reading a summary rather than the Regulation. The Commission attaches its own warning to that document: "This summary has been prepared by the Commission services and is not meant to systematically cover the full scope of the Regulation". Treat everything above as a developer working through a document in public, not as advice from anybody qualified to give it.
Two details that cut against the drama
The first goes against every vendor, including me. The reporting duty reaches backwards: "Reporting obligations apply to all products with digital elements that have been made available on the Union market, including those already placed on the market before 11 December 2027". Nothing is grandfathered by having shipped early.
The second goes the other way, and it removes most of the fear from the timeline for anybody small. Under the penalties chapter, "manufacturers that qualify as microenterprises or small enterprises may not be fined for failures to meet the 24h deadline for reporting vulnerabilities and severe incidents". The obligation applies to a one-person developer; the fine for missing the twenty-four hours does not. That is careful drafting, and it means the pressure on a small vendor is reputational and procedural rather than financial.
Two things this gives a buyer, before any of it takes effect
A manufacturer has to fix a support period, and the summary is specific about how it is communicated: "The end date of the support period (including month and year) needs to be clearly and understandably specified at the time of purchase". A camera product that cannot name the month its security fixes stop is going to be out of step with that, and a great many of them cannot name it today.
And the reporting platform is not restricted to vendors: "It is also possible for any natural or legal person to notify vulnerabilities, cyber threats, incidents and near misses on a voluntary basis through the CRA Single Reporting Platform". The route around a vendor who does not answer their mail is being built into the same system that is about to start timing them.
The asymmetry to watch for
From September there will be a growing record of manufacturers reporting exploited vulnerabilities, and the names appearing in it most often will not be the least careful ones. They will be the ones whose products talk back to them. A filed report says something definite. An empty row says two entirely different things at once, and looks the same either way: the product was quiet, or its maker had no means of finding out.
Mine has the store's crash feed and the contents of my inbox, and neither was built to answer the question the Regulation asks. I would rather say that here than let a year of empty rows imply the flattering reading of it. What I owe in exchange is the direction I can still control: an address that reaches a person when somebody does find something, and a support-period date that is an actual date rather than a posture.
The app I build for this is Background Camera RemoteStream, which records and streams from a spare Android phone with the screen off. The rest of the writing on running an old handset this way is at superfunicular.com.
Sources, all first-party: the European Commission's Cyber Resilience Act reporting obligations page and its summary of the legislative text for Regulation (EU) 2024/2847; and, for what the app store collects without being asked, Play Console Help on viewing crashes and ANR errors and Android vitals.
Top comments (0)