Does the Cyber Resilience Act Require Code Signing?

What the CRA actually says about signing

Nothing, in as many words. Search the regulation for "code signing" and you come back empty. The essential requirements in Annex I are written as properties a product must have and processes a manufacturer must run, kept deliberately technology-neutral so the text outlives whichever cryptography is fashionable when it is read. Two of those requirements are where signing earns its keep.

The first is the integrity requirement, Annex I Part I point 2(f). Products must "protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions." Read the object list slowly. It is not only user data, commands, programs and configuration are named, which pulls your executable and your firmware image squarely inside the sentence.

The second sits in the vulnerability-handling half. Annex I Part II point 7 requires manufacturers to "provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner." Part I point 2(c) approaches the same ground from the product side, asking that vulnerabilities can be addressed through security updates, automatically and on by default where that applies.

Put the two together and you have a product that can tell an authentic update from a forged one, plus a manufacturer who can keep pushing authentic updates for years. There is one well-understood way to make a file self-authenticating both in transit and once it has landed, and that is a digital signature over the file.

HTTPS is the answer people reach for first, and it solves a different problem. TLS protects the pipe. It tells the client that the bytes arrived from the server it connected to, without interference on the way. It says nothing about whether the artefact on that server was the one you built, nothing about the mirror or CDN edge or corporate proxy you do not operate, and nothing about the file once it is sitting on disk waiting to be installed. A signature attaches the authenticity claim to the artefact, so it survives every hop and every hour of storage between your build machine and the moment of execution.

One clause in 2(f) rewards a second look: "and report on corruptions." Detecting tampering is only half of what is asked. A verifier that spots a broken signature, writes a line to a log nobody reads and installs the update anyway has met neither the letter nor the point of the requirement. Rejecting and reporting is the behaviour being described.

Two dates, and only one of them involves signing

The CRA arrives in stages, and the stage arriving first has nothing to do with how you sign. From 11 September 2026 the reporting obligations apply. From 11 December 2027 everything else does: the Annex I essential requirements, conformity assessment, technical documentation and CE marking. The regulation itself entered into force on 10 December 2024, which started the clock without asking anything of anyone.

September 2026 is an incident-response obligation. Learn that a vulnerability in your product is being actively exploited, and you owe an early warning within 24 hours, a fuller notification within 72, and a final report within 14 days of a corrective measure becoming available. Severe incidents affecting the security of the product follow the same 24-and-72-hour rhythm with a month for the final report. Filing happens once, through the CRA Single Reporting Platform, which routes to the CSIRT where you have your main establishment and to ENISA.

Teams underestimate this one because it does not ask for a product change. It asks for a process, someone who watches for exploitation reports, someone who can be reached at the weekend, a decision path from "a researcher emailed us" to "a filing went in" that fits inside a day. Processes take longer to build than features, and this one has no grace period.

The signing question belongs to December 2027. That is when a product placed on the EU market has to carry a CE marking backed by a technical file that explains how each Annex I requirement is met, integrity and secure update distribution among them. There is a trap in treating December 2027 as the moment to begin: whatever support period you declare then binds you for at least five years afterwards, and the way you sign has to survive that whole stretch. Decisions made in a rush in late 2027 are decisions you will still be living with in 2033.

The question that decides it: who verifies the signature

The CRA does not say what kind of certificate to sign with, because it genuinely does not care. What settles the question is something the regulation never asks: when your update arrives, which piece of software checks the signature, and where does that software get its list of trusted issuers? Answer that honestly and the certificate decision makes itself.

In the first case the verifier is an operating system, or a person you will never meet. A Windows installer downloaded from your site passes through SmartScreen and User Account Control. A macOS application meets Gatekeeper. A kernel-mode driver has to satisfy the Windows driver-loading policy before it runs at all. In every one of those, the trust store belongs to Microsoft or Apple. You cannot add your key to it, your customers will not add it for you, and a self-signed binary produces exactly the warning you were trying to avoid. Only a certificate chaining to a root already in those programs will validate, which is what "publicly trusted" means in practice.

In the second the verifier is code you wrote, running on hardware you shipped. An OTA agent on an embedded device, a secure boot chain, an appliance that pulls signed bundles from your update server. The trust anchor is already compiled into the image or burned into fuses. Here a public certificate authority adds nothing the CRA asks for, and it quietly costs you something: if your updater is configured to trust a public root rather than your specific key, it now trusts every certificate that authority has ever issued to anybody, unless you pin harder on top. A narrow trust anchor you control is the stronger engineering answer as well as the cheaper one.

The third case is both at once, and it is more common than either pure case. A device ships with firmware and a Windows configuration tool. An industrial gateway comes with a driver. A camera has a mobile app and an OTA channel. Two verifiers means two signing problems, and they should not share a key: the blast radius of a compromised firmware key and a compromised installer key are different, and so are the recovery paths.

When a publicly trusted certificate is the answer

Once an operating system is your verifier, the requirements stop being yours to set. A publicly trusted code signing certificate comes in two validation levels, organisation-validated and extended-validation, and since June 2023 the private key for either has to live on hardware certified to FIPS 140-2 Level 2, Common Criteria EAL4+ or equivalent. That means a physical token posted to you, or a cloud signing service where the key is generated inside a hosted HSM and never leaves it.

Nothing in the CRA makes EV mandatory. Platform rules can, and they are the rules that will actually stop your build: Microsoft requires an EV certificate to submit a kernel-mode driver for attestation signing, and some enterprise buyers still write EV into a procurement policy. What EV stopped buying, in 2024, is a SmartScreen shortcut, Microsoft removed the instant-reputation treatment for EV signatures, so a brand-new EV-signed download warns exactly like an OV-signed one until it has a download history. For most software, OV is the proportionate choice. The differences between EV and OV code signing are worth walking through before the CRA conversation starts, because the answer rarely changes once the technical file is written.

Whichever level you land on, the deliverable for your CRA technical documentation is the same: a short, honest statement of which mechanism satisfies the Annex I integrity requirement, how the signing key is protected, who can invoke it, and what happens when verification fails. Auditors read that paragraph more carefully than they read your certificate.

When your own key is the better answer

For a closed system, a key you manage yourself is usually both sufficient and stronger. Your updater knows exactly which public key it will accept, so verification is a narrower check than any public PKI can offer, and you are not depending on a third party to stay in a root program for the length of your support period. The CRA asks whether the integrity of programs and configuration is protected. It does not ask who issued the certificate.

What replaces the certificate authority is discipline you now own outright. The signing key belongs in an HSM, not on a build agent. Key rotation has to be possible on a device already in the field, which usually means shipping more than one trust anchor from the start, because a fleet that can only ever trust one key is a fleet you cannot recover after a compromise. The updater needs rollback protection, or an attacker replays a genuinely signed but vulnerable old image straight past your signature check. And the verification failure path has to reject and report, which is that clause in 2(f) again.

Write all of it down as you build it. When the technical file is assembled in 2027, "we use our own PKI" is not an argument. "Here is the trust anchor, here is where the key lives, here is the rotation procedure, here is what the device does when verification fails, and here is the test that proves it" is one.

Five years of support against a 460-day certificate

Here is the collision almost nobody puts on one page. The CRA expects a support period that reflects how long the product will realistically be in use, and as a general rule at least five years. Since 1 March 2026 the maximum validity of a publicly trusted code signing certificate has been 460 days, cut from 39 months by CA/Browser Forum ballot CSC-31. Five years divided by 460 days is four certificates, minimum, for one product's supported life.

Timestamping is the part people reach for here, and it solves the other half of the problem. An RFC 3161 timestamp records that a signature existed while its certificate was valid, so an installer you shipped in year one still verifies in year five long after that certificate has expired. Without it, every signature you have ever made starts failing the day the certificate lapses, which would make a five-year support promise impossible on a 460-day certificate. Timestamp everything, every time.

What a timestamp cannot do is let you sign something new. The security update you owe a customer in year four has to be signed on the day you build it, with a certificate valid on that day. So your CRA support commitment and your certificate renewal calendar are the same calendar, and an expired certificate at the wrong moment is not a procurement inconvenience, it is a patch you cannot ship against a deadline the regulation sets for you. The 460-day validity change covers the mechanics of the shortened cycle in detail.

Two practical consequences follow. Organisation validation is revalidated on its own schedule, independent of the certificate, so a company that has moved office or changed its registered details can lose weeks at renewal on paperwork rather than cryptography. And because a renewal issues a new certificate, and almost always a new key with it, SmartScreen starts rebuilding certificate reputation for everything signed afterwards: four times over a five-year support period, on Windows. Files already shipped keep the reputation they earned, which is another argument for renewing early and overlapping rather than letting one certificate lapse before the next arrives.

Signing is one requirement out of many

A signed binary with no bill of materials and no advisory process fails Annex I just as surely as an unsigned one. Signing answers the integrity requirement and the secure-distribution requirement. It answers none of the documentation and disclosure obligations sitting beside them in Part II, and those are the ones that take longer to build.

Part II point 1 requires manufacturers to identify and document the vulnerabilities and components in their products, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies". Machine-readable is the operative phrase, a spreadsheet of libraries is not an SBOM. Top-level dependencies is the floor rather than the ceiling, and most teams find that generating the document is easy while keeping it accurate across every release is the actual work.

Point 8 covers what happens when a fix exists. Security updates have to be disseminated without delay and free of charge, with advisory messages telling users what has changed and what they may need to do. You cannot charge for a security fix, you cannot sit on it while it waits for the next quarterly release train, and you cannot ship it silently. Publishing structured advisories is the habit that turns this from a scramble into a routine.

It is worth being blunt about the marketing you will encounter. Any vendor selling a signing product as "CRA compliance" is describing one control out of a set. The signature is genuinely necessary for most products and it is genuinely not sufficient for any of them.

There is no standard to point at yet

As of August 2026, no CRA harmonised standard has been cited in the Official Journal of the European Union. The presumption of conformity under Article 27, the shortcut where conforming to a cited standard means you are treated as meeting the corresponding essential requirement, is therefore not yet available for any product category. You cannot currently write "we conform to EN X, therefore Annex I is satisfied" in your technical file, because there is no X to name.

Work is moving. The horizontal standards in the EN 40000 family have closed public enquiry and are under approval at CEN-CENELEC, and the Commission has pushed the original 2026 delivery deadlines back by two months. Article 27 only becomes available once a standard's reference is published in the Official Journal, which happens after delivery, assessment and a formal citation decision, so the gap between "approved" and "usable" will not close instantly.

Until then you document your own reasoning: which mechanism satisfies which requirement, and why that mechanism is adequate for this product. That is more work than citing a standard, and it is also the strongest argument for settling the signing decision now rather than in the last quarter of 2027. A justification written calmly while there is time to test it reads very differently from one written the week before a CE marking is due.

What to do before December 2027

Six things, roughly in the order they unblock each other.

The second row is the one everything else waits on. Teams that cannot answer "what checks this signature" tend to buy certificates they do not need for firmware, and skip the ones they do need for the installer that ships alongside it.

FAQ