A door lock you open with your phone. A camera that shows you the hallway while you’re at work. A baby monitor, an alarm. These products are turning up in more and more homes, and from December 2027 they will have to comply with the EU’s Cyber Resilience Act (CRA).

The law sets out what these products must achieve, but not how to get there technically. The practical guidance comes from standards. For smart home products with security functionalities, the relevant one is ETSI EN 304 632, Cybersecurity requirements for smart home products with security functionalities, which is intended to spell out how the law’s essential cybersecurity requirements for these products can be met in technical terms. The standard is expected to be finalised in early 2027.

We spoke to Kilian Mitterweger, rapporteur for the standard. He works in the Connected Living and Smart Cities division at BSI, the Bundesamt für Sicherheit in der Informationstechnik – Germany’s Federal Office for Information Security. He spends most of his working time on standardisation and advising on CRA matters.

The article in brief:

• Kilian Mitterweger on his work as rapporteur for ETSI EN 304 632
• Why smart locks and alarms face stricter scrutiny under the CRA
• How the standard is built, with a smart door lock as an example
• What the standard means for manufacturers of smart home products
• Where legal requirements are hardest to put into technical terms
• The current status of the standard, and what manufacturers can do now

Why smart locks and alarms face stricter scrutiny

Under the CRA, smart home products with security functionalities count as important products (class I), which means they face stricter scrutiny than most other consumer products. Kilian suggests two possible reasons for the legislator’s decision.

The first is consumer protection. Most people don’t have time to check whether a device is secure, and some products are used by or for more vulnerable groups, such as children and babies. That makes built-in, carefully assessed security more important for consumers than for professional users, who can configure and assess a product to suit their own needs.

The second is scale. The consumer market is huge, and these products tend to stay in use for a long time.

– Lots of insecure products on the market add up to a major risk to national infrastructure and to society. So, it makes sense to make sure all these products are secure, Kilian says.

Read also: Approved product under the CRA – Ted Strandberg on how companies can start preparing now

Kilian Mitterweger, BSI, rapporteur for ETSI EN 304 632

A step beyond today’s standards

The standard has to do two things at once, Kilian explains. It needs to deliver objectively verifiable cybersecurity that is proportionate to the risks, without forcing the market into unnecessary and burdensome changes to meet it. In the latest draft of the standard, the requirements depend on several factors: what the product is intended for and how it can reasonably be expected to be used, but also the environment it is used in and how exposed it is to threats.

EN 304 632 builds on two existing standards. The first is ETSI EN 303 645, Cyber Security for Consumer Internet of Things: Baseline Requirements, which since 2020 has served as a voluntary minimum level of cybersecurity for connected consumer products, with no link to any legislation. It was explicitly designed to be complemented by more specific standards for particular products.

– It’s still a very good foundation for cybersecurity, but it doesn’t quite fit EU product legislation, Kilian says.

The second is the CEN/CENELEC EN 18031 series, Common security requirements for radio equipment. With some restrictions, these provide presumption of conformity for the cybersecurity-related essential requirements of the Radio Equipment Directive (RED).

EN 304 632 brings the two together and goes further into the detail.

– The standard should say which requirement applies in which situation, how strong a security mechanism needs to be at a minimum and what that strength actually means. At the same time, it should be more or less technology-neutral, Kilian says.

How the vertical standard for smart homes works

The requirements in EN 304 632 are based on a generic model of how smart home products with security functionalities, such as locks, cameras and alarms, are put together. The model describes what functions the product has, what data it handles, what parts it is made up of and what interfaces it has, as well as the environment it is used in and by whom. A single product might, for example, consist of the device itself, a gateway, a mobile app and a cloud service.

The functions are divided into groups:

• functions that control something, such as locking or setting off an alarm
• functions that sense something, such as fire, gas, sound, images or tampering
• supporting functions for configuration, updates, authentication and logging

The requirements are then derived from the model. How strong a security mechanism needs to be depends on the function in question, how that function is accessed and the environment in which the component receiving the command is used.

What authentication does it take to open the front door with your phone?

At CRA Day on 4 May 2026, Kilian showed an example of how the standard is intended to work. The starting point is a mobile app that unlocks the door via Bluetooth.

The example is based on Kilian Mitterweger’s presentation at CRA Day 2026. Illustration: ITS.

Communication. Bluetooth is local communication between two devices, the phone and the lock, rather than a keypad or switch that someone operates directly on the lock.

Environment. A lock on a front door normally sits in a partially controlled environment, where only a limited number of people have access, or where strangers would attract attention.

Function. Opening a front door is a function whose use can cause harm, and the standard assigns it a high impact class.

The answer. Together, the three factors determine the requirement in the standard’s table: the app must support authentication at strength AUTH.Enhanced or higher.

The standard doesn’t say how the app should reach that level. It could be a user’s code or biometrics that releases an appropriate digital key, or another combination, as long as the mechanism is strong enough.

Where CRA requirements are hardest to translate into technology

Behind the example’s clear-cut answer lies a much harder job. A standard has to work in the real world of product development, security technology and costs, while also standing up to a legal framework with clear rules. Kilian describes it as two worlds that are hard to reconcile.

– The legal framework favours precise instructions, but in cybersecurity everything is a moving target and the boundaries are rarely sharp, Kilian says.

Just how detailed the standard should be is negotiated as the work goes on. Manufacturers want the freedom to choose their own solutions, while specific requirements offer greater legal certainty. Kilian expects the standards to start out fairly general and become more specific over time.

He sees two of the CRA’s essential requirements as particularly hard to translate. One concerns access control. From a security perspective, it’s tempting to require a clear model of which users can do what, but that quickly becomes very complex. At that point, the people writing the standard end up developing products instead of writing security requirements.

The other is the requirement for products to limit the impact of incidents. An exploited vulnerability shouldn’t mean that an attacker can take over the entire product. The techniques exist, but writing requirements that suit the sector is difficult.

– If we can’t find a good enough answer, the requirement becomes generic, and then it may not be enough for presumption of conformity, he says.

Then there are questions of interpretation. Which products are covered is determined by a product category in the CRA and a short technical description from the European Commission. The description runs to just a few lines, and there will always be products where it’s unclear whether they’re included. Interpreting the regulation isn’t the job of standardisation, Kilian stresses, but to write technical requirements you need to understand what the legislator meant. Where questions remain unanswered, despite the Commission doing its best to help, the requirements are worded so that the interpretation doesn’t become decisive.

What does the standard mean for manufacturers?

Kilian wouldn’t go as far as to say that all manufacturers of smart home products will need to change course. But he points to two areas where the change could be noticeable.

Logging. The CRA has an essential requirement on logging, and the standard scales it according to risk. For a product with a high impact class, such as a front door lock, it currently has to log, among other things:

• every login attempt
• changes to the configuration
• when the software starts, shuts down or fails
• every attempt to gain elevated privileges or to access data and functions

For consumer products, logging this much may be unusual. Kilian, however, sees it more as a result of efforts to meet the regulation than as something strictly necessary from a security point of view, particularly given the possible implications for users’ privacy.

Vulnerability handling. How vulnerabilities are to be handled once a product has been placed on the market is mainly covered by the CEN/CENELEC horizontal standard prEN 40000-1-3, which applies to all products under the CRA. For a front door lock, this means the manufacturer must be able to fix a vulnerability in the lock or in the app that controls it, and make sure the security update reaches users. In EN 303 645, fixing vulnerabilities in a timely manner is a recommendation. Under the CRA, it becomes a requirement.

– The fact that manufacturers will be obliged to fix vulnerabilities within a reasonable time, and that this will actually be checked, changes the way people work with IT security, Kilian says.

The standard doesn’t replace your own judgement

Like other standards, EN 304 632 is voluntary. But once it has been cited in the EU’s Official Journal, it is likely to become the simplest way to show that a product meets the CRA’s requirements, since it will then provide presumption of conformity. Following the standard doesn’t remove the need for judgement, though. Manufacturers need to identify the standard that fits their product and then map the product onto the standard’s generic model, in other words decide which parts of their own product correspond to which elements of the model. Because standards are written with certain threats and situations in mind, there will always be products that don’t fit perfectly. In those cases, according to Kilian, the manufacturer has to take a step back, ask what is reasonable from a security point of view, and make a decision.

Could the standard end up as just a checklist to tick off?

– If cybersecurity could be reduced to a box-ticking exercise, that would be fantastic. It would make the whole thing simple and efficient, Kilian says.

But he doesn’t think it can be done, or at least not easily. If insecure products are still approved because every item on the list has been met, the whole idea behind the regulation is at stake, he argues, and perhaps the credibility of the supervisory authorities too. That’s why the market needs to take the regulation seriously, and market surveillance needs to be strong enough to do a good job.

How standards drive innovation

Earlier in our article series on the CRA, Kim Nordström described how harmonised standards make it easier to comply with the law, leaving manufacturers free to spend their time on the product rather than on interpreting the rules. Kilian highlights another side of this. A standard that sets out which requirements apply and how they are to be assessed gives everyone the same yardstick, so that different technologies and solutions can be compared against each other.

– With a common language for security, it becomes clear what different solutions can and cannot do. That fosters innovation, Kilian says.

A standard that instead prescribes a particular technology closes off other routes and can steer development in the wrong direction. The line between the two isn’t always easy to draw.

Read also: Where innovation takes direction – before markets are established

From draft to harmonised standard

EN 304 632 is one of 17 vertical standards under the CRA that ETSI sent out for public enquiry this summer. The draft was open for combined public enquiry and vote between 20 July and 12 October 2026. This was the moment for manufacturers, authorities and other stakeholders to influence the content before the standard is approved.

During this period, the draft received nearly 300 comments. These focused mainly on aligning its details with the other vertical CRA standards for consumer IoT products (ETSI EN 304 631, ETSI EN 304 633 and ETSI EN 304 634), refining the cryptographic framework and making the standard more accessible, particularly by defining use cases and reducing complexity.

Based on the feedback so far, Kilian concludes that further work is needed in three areas: technical refinements, editorial improvements and stakeholder alignment on the appropriate level of detail.

Engagement that makes for a better standard

In Sweden, ITS coordinates national input on ETSI standards. All ETSI standards out for public enquiry are published on the ITS website. Comments can be submitted by anyone living in Sweden and by organisations with a Swedish organisation number.

Those comments then go to the ITS Standards Approval working group (WG SA). Meeting six to eight times a year, the group decides which Swedish comments are passed on to ETSI, and how Sweden casts its vote on each draft standard. WG SA submitted no comments during the enquiry and backed the draft of EN 304 632.

What has pleasantly surprised Kilian is how keen people are to contribute.

– In academia, in the public sector, in industry and among small and medium-sized enterprises, there are people who really want to contribute. They want to shape Europe’s future, to have secure products and a resilient society. It’s already great to see, but we need continued support from all stakeholders, Kilian says.

What happens next?

The next step is to work through the comments from the enquiry and for the standard to be reviewed by the Commission’s Harmonised Standards consultants (HAS). It will only provide presumption of conformity once it has been published and cited in the EU’s Official Journal.

Kilian’s advice to manufacturers

Kilian’s advice to manufacturers starts with getting to know their own product from a security point of view, including the components they build into it. A risk assessment is the foundation, but he urges them to go a step further.

– Every manufacturer should be aware that their product will have vulnerabilities. That’s why it needs to be designed so they can be fixed quickly and efficiently, Kilian says.

Want to help shape the standards of the future?

Find out more about the ITS Standards Approval working group (WG SA) and how you can get involved.

You can also get in touch to arrange a company visit from our CEO, Bettina Funk (page in Swedish).

Read more articles in the same series:

Inside ETSI TC CYBER – Kim Nordström on turning CRA law into finished standards

CRA standards play different roles – Angelo D’Amato explains which one will be decisive

Approved product under the CRA – Ted Strandberg on how companies can start preparing now

24 hours to act – how the CRA’s incident reporting works

How the CRA is shaping product development – forty products, one deadline at ASSA ABLOY