The EU Cyber Resilience Act’s reporting obligations take effect on 11 September 2026. Twenty-four days from today.

The mechanics are settled and widely documented. From that date, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements, or of a severe incident affecting the security of such a product, must submit an early warning within 24 hours, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability — or within one month for a severe incident. Reporting happens once, through the CRA Single Reporting Platform, addressed to the CSIRT of the manufacturer’s main establishment and made available simultaneously to ENISA.

Nearly all the published guidance is aimed at manufacturers: build the SBOM, stand up the PSIRT, wire up the reporting workflow. Fair enough — they carry the obligation. But most of our readers are on the other side of the transaction. You buy cameras, controllers, access control systems, gateways and conference room hardware, and you install them in buildings. Nothing in the CRA obliges you to report anything.

So the honest question is: does 11 September change anything for you at all?

Yes. Three things, and one of them is worth restructuring procurement around.

1. You Are About to Get Much More Information — Whether You Are Ready For It Or Not

Article 69(3) extends Article 14’s reporting requirements to products placed on the market before 11 December 2027. That is a deliberately wide net: it is not only new products. A device already installed in your building, still supported, with an actively exploited vulnerability, is in scope for its manufacturer’s reporting duty.

The practical consequence is that the volume of vendor security disclosures about devices you already own is going to increase — sharply, and starting in September. Vendors that historically handled a vulnerability with a quiet firmware release and a changelog line now have a regulated incentive to publish, and to publish fast.

That is good. It is also an operational load nobody has budgeted for. Ask yourself, concretely:

  • Who receives vendor security notices for the cameras? Not “IT” — a named person or a monitored mailbox.
  • Is anyone subscribed to the security advisory feed for your BMS, your VMS, your access control system, your door controllers, your UPS fleet? In most organisations the answer for at least three of those is nobody, because the integrator was assumed to be watching.
  • What is your process when an advisory arrives for a device that only the integrator can patch? If the answer involves raising a ticket and waiting, measure how long that has historically taken. That number is your real exposure window.

More disclosure only improves your security if something happens when a disclosure arrives. Between now and September, the highest-value thing you can do is build the intake path.

2. Vendor Responsiveness Becomes Measurable — and Therefore Buyable

Until now, “does this vendor fix things quickly?” has been almost impossible to assess at purchase time. You could ask, and you would get a marketing answer.

After September, a manufacturer selling into the EU that is aware of an actively exploited vulnerability has a legal deadline. That does not make every vendor fast, but it creates a public record where there was none, and it gives you something concrete to ask for.

The contrast with today’s baseline is stark. The camera zero-day we covered in July ran twelve months from researcher report to public advisory with no patch shipped, and the disclosing researchers’ only mitigation advice was to restrict interaction with the product. The DSC TL280 alarm communicator flaw was reported in February 2026 with a fix tracking to roughly September or October — a seven-to-eight-month cycle on a device whose entire purpose is signalling that someone has broken in.

Neither of those is unusual. Both become considerably harder to repeat quietly once there is a reporting platform, a regulator, and a timestamp.

3. Class I Changes Who Signs Off on Your Security Devices

This is the part most buyers have not internalised. Annex III of the CRA names “smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems” as Class I important products. That classification follows the product, not the room — the same camera model sold into a lobby carries it.

Class I products cannot simply be self-declared unless the manufacturer applies harmonised standards or an approved certification scheme. As of mid-2026, CRA harmonised standards had not been formally cited in the Official Journal, which leaves notified-body involvement — EU-type examination plus conformity verification — as the realistic route for Class I devices.

For a buyer, that translates into a question with a checkable answer: for a Class I device, which conformity route did the manufacturer take, and if it was self-assessment, against which harmonised standard? A vendor that cannot answer either has not started or is relying on a standard that does not exist yet.

The Six Questions to Add to Procurement This Month

Not a compliance programme. Six lines in an RFP or a purchase order, answerable in writing, that will separate serious vendors from the rest.

  1. Is this product in scope of the EU Cyber Resilience Act, and if so, at what classification — default, Class I, or Class II? Establish whether they have done the analysis at all.
  2. What is your conformity assessment route, and if self-assessment, against which harmonised standard or certification scheme? For Class I devices this is the question that has a factual answer.
  3. Will you provide an SBOM for this product, in what format, and how will it be updated across firmware releases? The reporting duty is unmeetable without component inventory; a vendor that cannot produce an SBOM cannot reliably know when a reportable vulnerability exists in their product.
  4. What is the declared support period for this product, and what is the end-of-support date for the specific model we are buying? The CRA expects security updates across the product’s expected lifetime. Get the date before purchase, not after the vendor stops answering.
  5. How will you notify us of a vulnerability in this product? Give the channel, the trigger, and the time commitment. Their regulatory duty runs to a CSIRT, not to you. Your notification is a contractual matter, so put it in the contract.
  6. Give two examples from the last 24 months: a third-party vulnerability report, and how long from receipt to shipped fix. The single most informative question on this list. A vendor with a functioning PSIRT answers it readily. A vendor without one changes the subject.

What Not to Expect

A few realistic caveats, because overselling this helps nobody:

  • The CRA does not make your devices secure. It makes vulnerability handling a regulated process. The Metasys, Desigo, Siveillance and Airwall flaws from last week’s advisory wave were all found and fixed under the current regime; the regulation changes the reporting and the accountability, not the existence of bugs.
  • It does nothing for unsupported devices. The end-of-life cameras with no vendor and no patch — the population feeding botnets like Dysphoria — sit entirely outside this. Your options there remain isolation or replacement.
  • Nothing happens visibly on 11 September. The obligation begins; the first reports flow to CSIRTs and ENISA, not to a public feed you can watch. The effect on buyers arrives gradually, through vendor behaviour and through what you can now demand in contracts.
  • Non-EU vendors sell into the EU too. Scope follows the market a product is placed on, not the manufacturer’s headquarters. That is precisely why the question belongs in procurement rather than in a legal review.

The Honest Summary

For manufacturers, 11 September is a deadline. For the organisations that buy and run connected offices, it is a lever — the first time vendor security process has been backed by something enforceable, and therefore the first time it can be a real purchasing criterion rather than a box on a questionnaire.

The buildings that benefit will be the ones that were already asking these questions and now have a regulation to point at. The buildings that do not will keep discovering, a year late, that the device watching the lobby has been shipping root to anyone on the same VLAN. The regulation does not fix that. Procurement does.