Status as of 11 August 2026. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements placed on the Union market. Commission practical guidance was published 27 July 2026. Reporting-related obligations apply from 11 September 2026; the main set of product obligations applies from 11 December 2027. This guide is for software engineers on products that may be in scope, not for conformity-assessment lawyers.
Scope honesty first: CRA is not a substitute for SOC 2, ISO 27001, or the GDPR. It is not "another compliance bot checkbox." Many CRA duties are manufacturer, documentation, and post-market processes. Only a slice erodes in a normal application pull request: dependency inventory and SBOM freshness, vulnerability disclosure routes, and security controls removed as dead code. If your legal or product team has not said CRA applies to what you ship, stop here and ask them.
What is in force when (developer calendar)
From 11 September 2026, reporting obligations associated with the Act's vulnerability and incident reporting regime begin to apply on the timeline the Regulation and Commission guidance set for manufacturers. From 11 December 2027, the main product cybersecurity requirements (including secure-by-design expectations, vulnerability handling processes, and SBOM-related transparency for products with digital elements) apply more broadly. Exact classification of your product (default, important, critical) is a legal and product question, not something a code review decides.
Treat those dates as planning anchors. If Official Journal corrigenda or further guidance move them, revalidate this page (see the date-freshness register).
What can actually show up in a pull request
Dependency and SBOM freshness: a change pins an outdated component, removes generation of a software bill of materials from CI, or stops publishing component inventory your vulnerability process relies on. Vulnerability handling path: a change removes or hard-codes shut a security contact, advisory feed, or internal vuln-triage webhook that your CRA-aligned process assumes exists. Secure-by-design erosion: a "cleanup" PR deletes authentication on an admin port, disables update checks, or turns off integrity verification on update packages because they were noisy.
Those are engineering shapes. They are not a full CRA conformity file, CE marking story, or notified-body assessment.
Worked example: CI stops emitting the component inventory
A platform team shortens CI by two minutes by deleting a job that ran syft (or equivalent) and uploaded an SBOM artifact on every release tag. The Dockerfile and app still build. Tests stay green. Review comments are about pipeline cost. Weeks later, the security team cannot answer "what versions shipped in 1.8.3" without reconstructing from layers.
If your product is in CRA scope and your process depends on that inventory for vulnerability handling and transparency, the deleted job is not neutral hygiene. A compliance-aware review flags the loss of the inventory step on the PR, so product and security can accept the risk formally or restore the job. heygrc citing a framework control here is a signal, not a determination that the product is non-conforming.
Explicit non-goals
This guide does not cover conformity assessment modules, CE marking, manufacturer registration, EU declaration of conformity drafting, or whether your product is "important" or "critical" under the Act. It does not claim heygrc makes a product CRA-compliant. It does not replace your PSIRT, legal review, or market-surveillance response plan.
If you only needed SOC 2 or ISO 27001 for customers, CRA may still be irrelevant. Do not force-fit it.
Where heygrc fits, and the honesty boundary
heygrc is built to surface control-relevant pull request changes against frameworks you enable. For CRA-adjacent engineering hygiene, the useful overlap is the same class of findings as secure development and vulnerability handling under other frameworks (for example NIS 2 Art. 21 software requirements, ISO 27001 secure development controls): removed update integrity checks, weakened auth, dropped inventory jobs. Map carefully; do not invent CRA article numbers on findings unless your enabled knowledge base includes them.
Keep SAST, dependency scanners, and your code reviewer. CRA product law is mostly outside the diff. The diff only catches the slice that quietly deletes what those programmes assume still runs.