Secani
Secani
  • Partners
Sign inTake the tour

Summarize with AI

Open in ChatGPTOpen in ClaudeOpen in PerplexityOpen in MistralOpen in Grok
SIBB Startups
Berlin
Co-funded by the European Union
for Startupsby
Secani

Jonathan Bezdek

Wörther Straße 9

10435 Berlin


hello@secani.com

Product

  • Secani Agent
  • Roadmap
  • Documentation
  • OSCAL
  • NIS2 applicability check
  • NIS2 implementation check
  • Frameworks

Legal

  • Privacy Policy
  • Terms
  • Cookie settings
  • Legal Notice
  • humans.txt
  • lawyers.txt
  • security.txt

Company

  • Company
  • Contact
  • Blog
  • Brand

Support

  • Help
  1. Start›
  2. Rammeværker›
  3. Cyber Resilience Act

Cyber Resilience Act.

Udvikl sikre produkter med digitale elementer, håndter sårbarheder, og forbered passende overensstemmelsesdokumentation.

  • Forordning (EU) 2024/2847
  • ·Af Derya Altinay
  • ·Status: 22.10.2026
  • ·Læsetid: 7 min.

Kort svar.

Cyber Resilience Act er EU-forordningen om cybersikkerhed for omfattede produkter med digitale elementer. Fabrikanter har ansvar for sikkerheden gennem udvikling, tilgængeliggørelse og support. Fabrikanternes indberetningspligter gælder siden den 11. september 2026; de generelle produktpligter gælder fra den 11. december 2027. Grundlaget er forordning (EU) 2024/2847.

Cyber Resilience Act og CRA-frister.

Cyber Resilience Act, forkortet CRA eller forordningen om cyberrobusthed, regulerer produkters cybersikkerhed. Forordning (EU) 2024/2847 forbinder designkrav med pligter i produktets livscyklus. Undersøgelsesobjektet er det konkrete produkt inklusive relevante komponenter og tilhørende fjerndatabehandling. Et sikkerhedsprogram for hele virksomheden kan understøtte dette arbejde, men besvarer ikke alene de produktspecifikke spørgsmål.

CRA-fristerne gælder trinvist. Efter art. 71, stk. 2, CRA begynder de generelle krav den 11. december 2027; fabrikanternes indberetninger efter art. 14 gælder allerede siden den 11. september 2026. Kapitel IV om notifikation af overensstemmelsesvurderingsorganer gælder siden den 11. juni 2026. Denne institutionelle dato er ikke en fremrykket generel CE-frist for alle softwareprodukter.

Ældre produkter er ikke generelt fritaget fra fabrikantindberetninger. Art. 69, stk. 2 og 3, CRA adskiller overgangsreglerne for produktoverensstemmelse fra indberetningerne. Kommissionens vejledning C(2026) 5252, afsnit 9.1, forklarer denne adskillelse også for produkter bragt i omsætning før december 2027. Vejledningen er en ikke juridisk bindende fortolkningshjælp; forordningen er fortsat afgørende.

Hvilke produkter og virksomheder CRA omfatter.

CRA vedrører omfattede hardware- og softwareprodukter, der tilgængeliggøres på EU-markedet, og som indebærer direkte eller indirekte dataforbindelse til en enhed eller et netværk. Art. 2 og 3 CRA fastlægger anvendelsesområde og begreber. Det kan omfatte særskilt udbudte komponenter. Undersøg den faktiske funktion og lovens undtagelser, før De klassificerer hele porteføljen ens.

Virksomhedens rolle bestemmer dens pligter. Fabrikanter, importører og distributører har forskellige opgaver; fabrikantrollen kan også være relevant ved markedsføring under eget varemærke. For open source-software skal kommerciel tilgængeliggørelse, enkeltpersoners bidrag og den særlige rolle som open source-softwareforvalter skelnes fra hinanden. En fri licens fritager ikke generelt fabrikanten af et kommercielt produkt fra ansvaret.

En SaaS-tjeneste falder ikke ind under eller uden for CRA alene på grund af sin salgsbetegnelse. Produktgrænsen og den tilhørende fjerndatabehandling er afgørende. Kommissionens vejledning, afsnit 2 og 8, skelner mellem softwareprodukter og fjernleverede tjenester. Dokumenter begrundelsen for den konkrete arkitektur; et generelt udsagn om alle cloud-tilbud ville være for vidtgående.

Hovedområderne i CRA-kravene.

CRA-kravene forbinder risikobaseret produktsikkerhed med løbende ansvar. Art. 13 og bilag I CRA danner grundlaget for produktpligterne; art. 14 regulerer de tidligere gældende fabrikantindberetninger. Følgende områder giver orientering uden at erstatte lovens enkelte krav.

  • Forstå produkt og risici.

    En cybersikkerhedsrisikovurdering understøtter sikkerhedsbeslutningerne gennem livscyklussen. Fabrikanter tager hensyn til tilsigtet og med rimelighed forudsigelig anvendelse. Beskriv i praksis produktets funktioner, grænseflader og afhængigheder, og hvilke konsekvenser et sikkerhedsproblem kan have for brugerne.

  • Indbyg sikkerhed i produktet.

    Sikkert design og sikre standardindstillinger hører sammen. Bilag I CRA omfatter produktegenskaber som adgangsbeskyttelse, databeskyttelse og begrænsning af angrebsflader. En efterfølgende udarbejdet politik kan ikke erstatte tekniske egenskaber; udviklingsbeslutninger og kontrollen af dem skal passe til risikovurderingen.

  • Integrer komponenter ansvarligt.

    Integrerede komponenter forbliver en del af produktvurderingen. Fabrikanter har brug for sporbare oplysninger om, hvad de leverer, og hvordan sårbarheder i afhængigheder berører produktet. Kommissionen beskriver udtrykkeligt den nødvendige omhu ved tredjepartskomponenter; blot at videreformidle en leverandøroplysning besvarer ikke alle produktspørgsmål.

  • Håndter sårbarheder og opdateringer.

    Sårbarhedshåndtering er en løbende opgave i den relevante supportperiode. Det omfatter tilgængelige indberetningsveje, vurdering, afhjælpning og sikker levering af sikkerhedsopdateringer. Adskil den tekniske behandling af et fund fra den juridiske vurdering af, om en aktivt udnyttet sårbarhed eller alvorlig hændelse er indberetningspligtig.

  • Fastlæg support og brugeroplysninger.

    Supportperioden afhænger af kriterierne i art. 13, stk. 8, CRA og den forventede anvendelse. Som udgangspunkt er mindst fem år foreskrevet; ved kortere forventet anvendelse gælder dens varighed, og ved længere forventet anvendelse kan en længere periode være nødvendig. Kommissionens vejledning, afsnit 5, forklarer udtrykkeligt, at fem år ikke er et generelt maksimum.

  • Muliggør fabrikantindberetninger.

    Art. 14 CRA skelner mellem aktivt udnyttede sårbarheder og alvorlige sikkerhedshændelser. Fabrikanter skal indberette trinvist: uden unødigt ophold, senest inden 24 timer en tidlig varsling og inden 72 timer yderligere oplysninger efter kendskab. Fristerne for afslutning varierer efter udløseren. Et scannerfund alene er derfor hverken automatisk indberetningspligtigt eller en tilstrækkelig grund til at afslutte hændelsen.

  • Forbered overensstemmelse og dokumentation.

    Teknisk dokumentation og overensstemmelsesvurdering skal forklare det udbudte produkt. Art. 32 CRA og produktkategorien bestemmer den tilladte procedure. Dokumenter det valgte vurderingsgrundlag sammen med produktversionen; en generel dokumentsamling uden sporbar forbindelse til den undersøgte udførelse er ikke tilstrækkelig som praktisk dokumentationsstrategi.

CRA-implementering som produktproces.

  1. Afgræns portefølje og roller.

    Registrer som praktisk begyndelse de udbudte produkter, deres relevante funktioner, den ansvarlige juridiske enhed og rollen i den enkelte salgskanal.

  2. Hold anvendelsesfaser adskilt.

    Adskil det allerede gældende beredskab til fabrikantindberetninger fra forberedelsen af generel produktoverensstemmelse, og undersøg overgange for eksisterende produkter.

  3. Omsæt risici til produktbeslutninger.

    Forbind risikovurderingen med design, komponentvalg og kontrollerbare sikkerhedskriterier for udvikling og frigivelse.

  4. Afprøv indberetningsveje.

    Udpeg ansvarlige og stedfortrædere, og øv vurdering, eskalation og indsendelse med ufuldstændige oplysninger inden for de gældende frister.

  5. Fastlæg support og dokumentationsvej.

    Planlæg vedligeholdelse af understøttede produktversioner, og afklar ud fra kategorien, hvilken overensstemmelsesvurdering og teknisk dokumentation der bliver nødvendig.

CE-mærkning af software og produktdokumentation.

CRA-dokumentationen er en produktrelateret overensstemmelsesvurdering. Kommissionen forklarer om art. 32 CRA, at en intern vurdering er mulig for standardkategorien. For bestemte vigtige eller kritiske produkter gælder strengere procedurer med et bemyndiget organ eller andre tilladte dokumentationsveje. Den faktiske produktfunktion afgør kategorien; et markedsføringsnavn er ikke tilstrækkeligt.

EU-overensstemmelseserklæringen og CE-mærkningen følger den gældende procedure. De er ikke et generelt certifikat for hele virksomheden eller et løfte om, at produktet aldrig vil have sårbarheder. En ensartet certifikatgyldighed passer derfor ikke som beskrivelse af CRA: Dokumentation, sårbarhedshåndtering og de til enhver tid gældende pligter skal betragtes gennem den relevante livscyklus.

Læs videre på bloggen.

  • Integrer CRA-pligter i produktudviklingenForbind produktgrænse, komponenter, releasedokumentation og indberetningsdrejebog i udviklingshverdagen.

Andre rammeværker og selvstændige pligter.

ISO 27001 organiserer et ledelsessystem for informationssikkerhed; et tilsvarende certifikat bekræfter ikke alene et produkts CRA-overensstemmelse. NIS2 ser på omfattede enheder og deres sikkerhedsorganisation. GDPR beskytter personoplysninger, og en produkthændelse kan derfor udløse yderligere databeskyttelsesspørgsmål. Beslægtede arbejdsgange kan koordineres, men deres juridiske udløsere og dokumentation skal fortsat undersøges særskilt.

  • ISO 27001Forstå rammen for et ISMS og dets certificering.
  • Implementer NIS2Forstå pligterne for omfattede enheder i Tyskland.
  • GDPRUndersøg databeskyttelsespligter uafhængigt af produktsikkerheden.

I Secani.

Secani indeholder et redaktionelt CRA-arbejdskatalog med kilder, kontrolspørgsmål og dokumentationseksempler. Virksomhedsprofilen registrerer blandt andet roller og vurderingsdato; uafklarede forudsætninger forbliver synlige som undersøgelsesbehov. Hjælpemidlet understøtter organiseringen af undersøgelsen, men bekræfter hverken den juridiske klassificering eller et produkts overensstemmelse.

Begynd med et afgrænset produkt.

Vælg et konkret produkt, og afklar først grænsen, den ansvarlige juridiske enhed og de ansvarlige for sikkerhedsindberetninger. Undersøg derefter, hvilke nuværende og kommende pligter der vedrører produktet. Denne start gør forberedelsen overskuelig og forhindrer, at et generelt complianceprojekt skjuler det allerede nødvendige indberetningsberedskab.

Anmod om en demo

Kilder.

  • Forordning (EU) 2024/2847 – Cyber Resilience Act
  • Europa-Kommissionen: Cyber Resilience Act og anvendelsesdatoer
  • Europa-Kommissionen: resumé af retsakten
  • Europa-Kommissionen: fabrikantpligter
  • Europa-Kommissionen: overensstemmelsesvurdering
  • Europa-Kommissionen: CRA og open source
  • Europa-Kommissionen: vejledning C(2026) 5252 med bilag

Ofte stillede spørgsmål.

Ja, for omfattede fabrikanter gælder indberetninger efter art. 14 CRA siden den 11. september 2026. De generelle produktpligter begynder den 11. december 2027; særlige roller og overgange skal undersøges særskilt.

Nej, betegnelsen SaaS afgør ikke anvendelsesområdet. Undersøg softwareproduktet, dets funktioner og den tilhørende fjerndatabehandling ud fra den konkrete arkitektur.

Nej, den særlige behandling af forudgående open source-bidrag fritager ikke generelt den kommercielle produktfabrikant fra sine pligter. Fabrikantrollen og en mulig rolle som softwareforvalter skal holdes adskilt.

Nej, et ISO 27001-certifikat vedrører et afgrænset ledelsessystem. CRA kræver en særskilt vurdering af produktet og den til enhver tid gældende overensstemmelsesdokumentation.

Organiser produktsikkerhed sporbart.

Arbejd struktureret med CRA-krav og kontrollen af dem i Secani.

Anmod om en demo

Denne side forklarer Cyber Resilience Act generelt og erstatter ikke en juridisk undersøgelse af det enkelte produkt. De gældende retsakter er afgørende.