GDPR vs. the Cyber Resilience Act: what is actually different
GDPR governs personal data. The Cyber Resilience Act governs product security. Most connected product teams need both, not one instead of the other.
If you have already been through a GDPR compliance project, the Cyber Resilience Act can feel like more of the same. It is not. GDPR and the CRA are enforced by different authorities, audit different things, and answer different questions, and treating the CRA as "GDPR for hardware" is the single most common mistake we see connected product teams make when they start scoping it.
TL;DR: GDPR (Regulation (EU) 2016/679) regulates personal data processing. The Cyber Resilience Act (Regulation (EU) 2024/2847) regulates the cybersecurity of products with digital elements. A connected product with a companion app and a user account is very likely subject to both, and being compliant with one does not make you compliant with the other.
What is the actual difference between GDPR and the CRA?
GDPR asks: what personal data do you collect, why, and how do you protect it. The CRA asks: is your product secure by design, does it ship with known exploitable vulnerabilities, and can you patch it when a new one is found. GDPR is about data. The CRA is about the product itself, and it applies even to devices that never touch personal data, an industrial sensor with no user account is squarely in CRA scope and entirely outside GDPR's.
Does being GDPR compliant help with the CRA at all?
Only tangentially. A mature GDPR program usually means you already have documented data flows, a designated compliance owner, and an incident-response habit, all useful organisational muscle. But none of that produces a Software Bill of Materials, a vulnerability-disclosure process, or a 24-hour active-exploitation reporting pipeline, which are the CRA's actual asks. Teams that assume GDPR readiness covers the CRA usually discover the gap during a conformity assessment, which is a worse time to find out.
Do the two regulations regulate the same companies?
Mostly, yes, but for different reasons. If your product has a mobile app, cloud dashboard, or account system, you are almost certainly processing personal data and therefore in GDPR scope. If your product has any digital element, firmware, an app, network connectivity, you are almost certainly in CRA scope too. The overlap in company population is high even though the obligations do not overlap in substance. Both regulations also reach companies established outside the EU based on market impact rather than location, we cover the CRA's version of that in does the CRA apply outside the EU.
When does a security incident trigger both regulations at once?
This is where the two do intersect. Under the CRA, an actively exploited vulnerability or a severe security incident triggers a 24-hour early-warning obligation to your national CSIRT and ENISA. If that same incident exposed personal data, GDPR's own 72-hour breach-notification duty to your data protection authority kicks in separately. These are two distinct filings, to two distinct regulators, on two distinct clocks. Good CRA practice, knowing what is deployed and patching fast, reduces how often this happens, but it does not merge the paperwork.
What is the fine structure difference?
GDPR fines scale up to EUR 20 million or 4% of global annual turnover, whichever is higher. CRA fines for breaches of the essential requirements scale up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Both are calculated on turnover, not on the product line involved, so the exposure is company-wide either way.
Which regulator enforces which one?
GDPR is enforced by national data protection authorities, the ones you already deal with if you have run a GDPR project. The CRA is enforced by market surveillance authorities designated per member state, working alongside ENISA and national CSIRTs for the reporting side. These are frequently different offices with different expectations, so a GDPR compliance relationship does not transfer.
Do I need to run these as one program or two?
Two programs, one shared calendar. Keep them as separate compliance tracks with separate owners and separate documentation, GDPR's data-processing register is not the same artifact as the CRA's SBOM and vulnerability log, but coordinate the incident-response process so a single security event triggers both notification paths without anyone having to remember on the day. For the full scope of what the CRA specifically requires, see our Cyber Resilience Act framework page and the CRA readiness checklist.
Where Scadable fits
Scadable is built for the CRA half of this, not the data-protection half. It maps every device and component you have shipped to the vulnerabilities that affect them, flags active exploitation, writes and backports the fix, and files the 24-hour report when the clock starts. If you already have GDPR handled and the CRA is the gap, book a walkthrough.
Last reviewed: July 1, 2026.
Frequently asked questions
Is the Cyber Resilience Act the same as GDPR? No. GDPR (Regulation (EU) 2016/679) governs how you collect, store, and process personal data. The CRA (Regulation (EU) 2024/2847) governs the cybersecurity of products with digital elements, hardware and software, regardless of whether they process personal data at all.
If I am already GDPR compliant, am I covered for the CRA? No. GDPR compliance says nothing about whether your product ships with exploitable vulnerabilities, carries an SBOM, or has a patching process. The two regulations audit different things and neither substitutes for the other.
Does the CRA replace any GDPR obligations? No. If your connected product also collects personal data, for example device telemetry linked to a user account, GDPR still applies in full. The CRA adds obligations, it does not remove existing ones.
Do the two regulations ever overlap? Yes, indirectly. A CRA-driven security incident, such as a breach caused by an unpatched vulnerability, can also trigger GDPR breach-notification duties if personal data was exposed. Strong CRA practices reduce that risk, but the two reporting obligations are separate and both need to be tracked.
Which one applies to my company? If you process personal data of people in the EU, GDPR applies. If you place a product with digital elements on the EU market, the CRA applies. Most hardware and IoT companies with a connected product and a customer account system are subject to both at once.