[{"data":1,"prerenderedAt":333},["ShallowReactive",2],{"blog-posts-en":3,"blog-post-what-cra-compliance-takes-for-a-small-hardware-team":80},[4,17,28,34,44,53,64,72],{"path":5,"stem":6,"title":7,"description":8,"date":9,"tags":10,"readingTime":15,"lang":16},"/blog/what-cra-compliance-takes-for-a-small-hardware-team","blog/what-cra-compliance-takes-for-a-small-hardware-team","What CRA compliance actually takes for a small hardware team","I turned every Cyber Resilience Act obligation for device makers into one checklist. What it asks of a connected product, and what I would do first.","2026-10-04",[11,12,13,14],"cra","iot","security","compliance","8 min read","en",{"path":18,"stem":19,"title":20,"description":21,"date":22,"tags":23,"readingTime":27,"lang":16},"/blog/one-golden-certificate-for-the-whole-production-line","blog/one-golden-certificate-for-the-whole-production-line","One golden certificate for the whole production line","Give every device its own X.509 identity in AWS IoT Core without flashing certificates unit by unit, using a shared claim certificate and fleet provisioning.","2026-10-01",[12,24,13,25,26],"aws","provisioning","esp32","9 min read",{"path":29,"stem":30,"title":31,"description":32,"date":22,"tags":33,"readingTime":27,"lang":16},"/blog/the-cra-clock-is-already-running","blog/the-cra-clock-is-already-running","The CRA clock is already running on devices you shipped years ago","Since 11 September 2026 the CRA's 24-hour reporting duty covers every connected product on the EU market, old ones too. What it means for a small hardware team.",[11,12,13,14],{"path":35,"stem":36,"title":37,"description":38,"date":39,"tags":40,"readingTime":43,"lang":16},"/blog/updating-firmware-on-a-fleet-without-bricking-it","blog/updating-firmware-on-a-fleet-without-bricking-it","Updating firmware on fifty thousand ESP32s without bricking any","Over-the-air updates for a large ESP32 fleet: partition layout and rollback, signed images, staged rollouts and the cost of sending a megabyte to every device.","2026-09-30",[12,26,41,42],"firmware","ota","7 min read",{"path":45,"stem":46,"title":47,"description":48,"date":39,"tags":49,"readingTime":43,"lang":16},"/blog/where-the-battery-goes-on-an-lte-m-sensor","blog/where-the-battery-goes-on-an-lte-m-sensor","Where the battery goes on an LTE-M sensor","The power budget of a battery powered LTE-M sensor, why the radio dominates it, and the settings that decide whether a battery lasts one year or five.",[12,50,51,52],"embedded","lte-m","low-power",{"path":54,"stem":55,"title":56,"description":57,"date":58,"tags":59,"readingTime":63,"lang":16},"/blog/building-an-llm-trading-bot","blog/building-an-llm-trading-bot","So everyone is building LLM trading bots now","I kept hearing about language models that trade on their own, so I dug into how these bots work, where they fall apart and what I would build instead.","2026-09-29",[60,61,62],"ai","llm","trading","6 min read",{"path":65,"stem":66,"title":67,"description":68,"date":58,"tags":69,"readingTime":71,"lang":16},"/blog/jev-a-model-that-only-decides","blog/jev-a-model-that-only-decides","JEV: a model that only decides","TypeSafe AI's JEV returns typed answers with calibrated probabilities and never writes a word. What it is, where it fits, and what to be careful about.",[60,61,70],"jev","5 min read",{"path":73,"stem":74,"title":75,"description":76,"date":58,"tags":77,"readingTime":15,"lang":16},"/blog/storing-a-reading-a-minute-from-100k-devices","blog/storing-a-reading-a-minute-from-100k-devices","Storing a reading a minute from 100,000 devices","What it actually takes to ingest, deduplicate and keep a year of per-minute telemetry from a fleet of a hundred thousand devices, and where the costs hide.",[12,78,79],"data-engineering","timescaledb",{"original":81,"pl":209},{"id":82,"title":7,"author":83,"body":84,"date":9,"description":8,"extension":201,"lang":16,"meta":202,"navigation":203,"path":5,"readingTime":15,"seo":204,"sitemap":205,"stem":6,"tags":206,"updated":207,"__hash__":208},"blog/blog/what-cra-compliance-takes-for-a-small-hardware-team.md","Bartosz Szczepanik",{"type":85,"value":86,"toc":190},"minimark",[87,97,102,105,108,112,115,118,122,129,136,140,143,146,150,153,156,159,163,166,169,172,176,187],[88,89,90,91,96],"p",{},"After I wrote about the reporting duty that started in September, the question I got most often was a simple one. Fine, we can report, so what else is there? Most of the answers floating around are either a two-line summary that says \"secure by design\" and stops there, or a hundred-page consulting deck. I wanted something in between, so I sat down with the regulation, the annexes and the Commission guidance from July and wrote down every obligation a manufacturer of a connected product actually has. The result became a ",[92,93,95],"a",{"href":94},"/cra/readiness","readiness checklist"," on this site. This post is the reasoning behind it.",[98,99,101],"h2",{"id":100},"two-dates-and-the-unit-that-matters","Two dates, and the unit that matters",[88,103,104],{},"The CRA has two dates a hardware company needs to care about. The reporting obligation in Article 14 has applied since 11 September 2026, to every product on the EU market, including units you sold years ago. Everything else applies from 11 December 2027.",[88,106,107],{},"The detail that changes planning is what \"placed on the market\" means. The Commission guidance is explicit that it applies to each individual unit. A sensor model you have been selling since 2023 does not get a pass in December 2027. The units already sold stay outside the design requirements, but every unit that leaves your warehouse from 11 December 2027 has to meet all of them. If your product line will still be shipping then, the work below applies to it, and with hardware lead times that work starts now.",[98,109,111],{"id":110},"the-risk-assessment-everything-hangs-on","The risk assessment everything hangs on",[88,113,114],{},"Article 13 asks for a documented cybersecurity risk assessment, based on the intended purpose, the reasonably foreseeable use, the environment the product works in and how long it will be in use. It sounds like paperwork, and in a way it is, but it is also the document the rest of the regulation is built on. For each of the thirteen security properties in Annex I, the assessment has to say how you meet it or why it does not apply. A requirement you simply skip is the easiest thing for a market surveillance authority to find.",[88,116,117],{},"The backend belongs in that assessment too. The CRA counts remote data processing that the device needs for its functions as part of the product, so the API, the MQTT broker configuration and the provisioning service are in scope along with the firmware.",[98,119,121],{"id":120},"the-thirteen-properties","The thirteen properties",[88,123,124,125,128],{},"When I first read Annex I Part I, I was relieved. Most of it describes what a careful IoT team already does. Ship without known exploitable vulnerabilities. Be secure by default, with a way to reset the device to its original state. Protect against unauthorised access, which in practice means per-device credentials and authenticated local interfaces. I wrote about one way to get ",[92,126,127],{"href":18},"unique device identities through a production line"," a few days ago. Protect the confidentiality and integrity of data, commands, firmware and configuration, which is TLS, secure boot and signed images. Limit the attack surface, which on a device means the JTAG and UART ports are locked in production and the test endpoints are gone.",[88,130,131,132,135],{},"A few of the thirteen are less obvious and deserve a careful read. Security updates have to be possible, and where applicable they should install automatically by default within an appropriate timeframe, with a clear opt-out, a notification that an update is available and an option to postpone it. That is a product decision as much as a firmware one, and it is worth settling now, because changing update behaviour on a fleet later is painful. I covered the mechanics of ",[92,133,134],{"href":35},"updating a large fleet safely"," in an earlier post. The product also has to record and monitor relevant internal activity, such as access to or changes of data and functions, and give the user a way to opt out of that. It has to let users remove all their data and settings permanently. And it has to minimise its negative effect on other devices and networks, which for a fleet mostly means reconnecting with backoff and jitter so ten thousand devices do not hammer a service at the same second after an outage.",[98,137,139],{"id":138},"handling-vulnerabilities-for-years","Handling vulnerabilities for years",[88,141,142],{},"Annex I Part II is about processes. You need an SBOM for every release in a common machine-readable format, covering at least the top-level dependencies. You fix vulnerabilities without delay and, where technically feasible, ship security fixes separately from new features. You test the security of the product regularly. Once a fix is out, you publish what the vulnerability was, which products it affects, how severe it is and what users should do. You run a coordinated vulnerability disclosure policy and publish a contact where people can report problems, including problems in third-party components you integrate. Updates have to be distributed securely, and security updates go out free of charge with a message telling users what to do.",[88,144,145],{},"Two numbers from Article 13 are easy to miss. The support period must be at least five years, longer if the product is expected to be used longer, and its end date, at least month and year, has to be visible at the time of purchase. Every security update you publish must then stay available for at least ten years or the rest of the support period, whichever is longer. If your update server and signing keys are not planned for that horizon, they should be.",[98,147,149],{"id":148},"paperwork-conformity-and-the-ce-mark","Paperwork, conformity and the CE mark",[88,151,152],{},"Annex II lists what the user information has to contain, from the vulnerability contact and the support end date to instructions for secure setup, updating and decommissioning. Annex VII lists the technical documentation, which pulls together the product description, the architecture, the vulnerability handling processes, the risk assessment, the reasoning behind the support period, test reports and the declaration of conformity. Both have to be kept for ten years, or for the support period if that is longer.",[88,154,155],{},"How you prove conformity depends on the category. For a default product, which covers most sensors, trackers and controllers, you can assess it yourself under internal control. Important products in class I can only do that when they apply harmonised standards, common specifications or a certification scheme in full. Harmonised standards for the CRA are still being finalised, so in practice many class I manufacturers should plan for a notified body. Class II always needs one, and critical products such as smart meter gateways may need a European certificate. The rules for notified bodies have applied since June 2026, and I expect their calendars to fill up well before December 2027. After that comes the EU declaration of conformity and the CE marking, which for most of us will sit alongside the Radio Equipment Directive in a single declaration.",[88,157,158],{},"The fines are worth knowing even if nobody plans to pay them. Breaching the essential requirements or the obligations in Articles 13 and 14 can cost up to fifteen million euros or two and a half percent of worldwide turnover, whichever is higher.",[98,160,162],{"id":161},"what-i-would-do-first","What I would do first",[88,164,165],{},"If I were running engineering at a small hardware company today, I would start with reporting, because it already applies and it is mostly about people and accounts. Register on ENISA's platform, decide who makes the call at two in the morning, know which firmware versions run in which countries, and set up a daily check of your SBOMs against lists of actively exploited vulnerabilities.",[88,167,168],{},"Next I would go after everything that needs a firmware or hardware change, because those take product cycles. Secure boot, signed updates with rollback protection, per-device credentials, locked debug ports and an SBOM generated by the build. If a board revision is needed to fit a secure element or lock down a debug interface, finding that out in 2026 is a lot cheaper than finding it out in late 2027.",[88,170,171],{},"The documentation comes last, and it goes much faster when the engineering already exists. A risk assessment written after the design decisions are made mostly records reasons you already had. A technical file assembled from a build pipeline that produces SBOMs and test reports on every release is mostly links.",[98,173,175],{"id":174},"the-checklist","The checklist",[88,177,178,179,181,182,186],{},"I put all of this into a ",[92,180,95],{"href":94},". Three questions about your product adjust it to your situation, then each item can be marked done, in progress, to do or not applicable, with a reference to the article or annex it comes from. It runs in your browser, keeps your answers on your device and gives you a Markdown gap report to take to your team. If you are not yet sure the CRA covers your product at all, the ",[92,183,185],{"href":184},"/cra/scope-check","scope check"," is the place to start.",[88,188,189],{},"None of this is legal advice, and the harmonised standards will refine how individual requirements are met once they are published. The structure of the obligations is in the regulation itself, though, and it is not going to change. If your team is looking at that list and wondering where to begin, I am happy to help.",{"title":191,"searchDepth":192,"depth":192,"links":193},"",2,[194,195,196,197,198,199,200],{"id":100,"depth":192,"text":101},{"id":110,"depth":192,"text":111},{"id":120,"depth":192,"text":121},{"id":138,"depth":192,"text":139},{"id":148,"depth":192,"text":149},{"id":161,"depth":192,"text":162},{"id":174,"depth":192,"text":175},"md",{},true,{"title":7,"description":8},{"loc":5},[11,12,13,14],null,"GrW3vIuKph9-82CE2Ss4QHbh9-daqrtcw66w9k2jyhQ",{"id":210,"title":211,"author":83,"body":212,"date":9,"description":326,"extension":201,"lang":327,"meta":328,"navigation":203,"path":5,"readingTime":329,"seo":330,"stem":6,"tags":331,"updated":207,"__hash__":332},"blogPl/blog/what-cra-compliance-takes-for-a-small-hardware-team.md","Czego CRA naprawdę wymaga od małej firmy sprzętowej",{"type":85,"value":213,"toc":317},[214,222,226,229,232,236,239,242,246,254,262,266,269,272,276,279,282,285,289,292,295,298,302,314],[88,215,216,217,221],{},"Po wpisie o obowiązku zgłaszania, który zaczął obowiązywać we wrześniu, najczęściej słyszałem jedno proste pytanie: dobrze, zgłaszać już umiemy, a co poza tym? Większość odpowiedzi krążących w sieci to albo dwuzdaniowe podsumowanie, które kończy się na haśle „secure by design”, albo stustronicowa prezentacja od firmy doradczej. Brakowało mi czegoś pośrodku. Usiadłem więc z rozporządzeniem, załącznikami i lipcowymi wytycznymi Komisji i spisałem każdy obowiązek, jaki faktycznie ma producent urządzenia z łącznością. Tak powstała ",[92,218,220],{"href":219},"/pl/cra/readiness","checklista gotowości",", którą znajdziesz na tej stronie. W tym wpisie wyjaśniam, skąd wzięła się jej zawartość.",[98,223,225],{"id":224},"dwie-daty-i-każdy-egzemplarz-z-osobna","Dwie daty i każdy egzemplarz z osobna",[88,227,228],{},"Firma sprzętowa musi pamiętać o dwóch datach z CRA. Obowiązek zgłaszania z artykułu 14 stosuje się od 11 września 2026 do każdego produktu na rynku UE, także do egzemplarzy sprzedanych lata temu. Cała reszta obowiązuje od 11 grudnia 2027.",[88,230,231],{},"O planowaniu decyduje jednak to, co oznacza „wprowadzenie do obrotu”. Wytyczne Komisji mówią wprost, że chodzi o każdy pojedynczy egzemplarz. Model czujnika, który sprzedajesz od 2023 roku, nie dostanie w grudniu 2027 żadnej taryfy ulgowej. Egzemplarze już sprzedane pozostają poza wymaganiami projektowymi, ale każdy, który wyjedzie z magazynu od 11 grudnia 2027, musi spełniać je wszystkie. Jeśli twoja linia produktów będzie wtedy nadal w sprzedaży, wszystko, co opisuję poniżej, jej dotyczy, a przy czasach realizacji w sprzęcie tę pracę trzeba zacząć już teraz.",[98,233,235],{"id":234},"ocena-ryzyka-na-której-wisi-cała-reszta","Ocena ryzyka, na której wisi cała reszta",[88,237,238],{},"Artykuł 13 wymaga udokumentowanej oceny ryzyka cyberbezpieczeństwa, która uwzględnia przewidziane zastosowanie produktu, racjonalnie przewidywalne użycie, środowisko, w którym pracuje, i to, jak długo będzie używany. Brzmi to jak papierologia i w pewnym sensie nią jest, ale na tym dokumencie opiera się cała reszta rozporządzenia. Dla każdej z trzynastu właściwości bezpieczeństwa z załącznika I ocena musi wskazać, w jaki sposób ją spełniasz albo dlaczego nie ma ona zastosowania. Wymaganie, które po prostu pominiesz, organ nadzoru rynku znajdzie najłatwiej.",[88,240,241],{},"W tej ocenie musi się znaleźć także backend. CRA traktuje zdalne przetwarzanie danych, którego urządzenie potrzebuje do realizacji swoich funkcji, jako część produktu, więc API, konfiguracja brokera MQTT i usługa provisioningu podlegają regulacji na równi z firmware.",[98,243,245],{"id":244},"trzynaście-właściwości","Trzynaście właściwości",[88,247,248,249,253],{},"Kiedy pierwszy raz przeczytałem część I załącznika I, odetchnąłem z ulgą. Większość wymagań opisuje to, co staranny zespół IoT i tak już robi. Produkt nie może trafić na rynek ze znanymi podatnościami, które da się wykorzystać. Ma być domyślnie bezpieczny i pozwalać na przywrócenie urządzenia do stanu pierwotnego. Ma chronić przed nieuprawnionym dostępem, co w praktyce oznacza osobne dane uwierzytelniające dla każdego urządzenia i uwierzytelnione interfejsy lokalne. Kilka dni temu pisałem o jednym ze sposobów na ",[92,250,252],{"href":251},"/pl/blog/one-golden-certificate-for-the-whole-production-line","nadanie urządzeniom unikalnych tożsamości na linii produkcyjnej",". Ma chronić poufność i integralność danych, poleceń, firmware i konfiguracji, czyli w praktyce TLS, secure boot i podpisane obrazy. Ma wreszcie ograniczać powierzchnię ataku, co w urządzeniu oznacza zablokowane w produkcji porty JTAG i UART oraz usunięte endpointy testowe.",[88,255,256,257,261],{},"Kilka z tych trzynastu wymagań jest mniej oczywistych i warto przeczytać je uważnie. Aktualizacje bezpieczeństwa muszą być w ogóle możliwe, a tam, gdzie ma to zastosowanie, powinny domyślnie instalować się automatycznie w odpowiednim terminie, z jasną możliwością rezygnacji, powiadomieniem o dostępnej aktualizacji i opcją jej odłożenia. To w równym stopniu decyzja produktowa, co kwestia firmware, i lepiej podjąć ją teraz, bo późniejsza zmiana zachowania aktualizacji na całej flocie jest bolesna. Jak ",[92,258,260],{"href":259},"/pl/blog/updating-firmware-on-a-fleet-without-bricking-it","bezpiecznie aktualizować dużą flotę",", opisałem we wcześniejszym wpisie. Produkt musi też rejestrować i monitorować istotną aktywność wewnętrzną, na przykład dostęp do danych i funkcji albo ich zmiany, i dawać użytkownikowi możliwość wyłączenia tego. Musi pozwalać użytkownikom trwale usunąć wszystkie swoje dane i ustawienia. Do tego musi ograniczać swój negatywny wpływ na inne urządzenia i sieci, co przy flocie sprowadza się głównie do ponownego łączenia z backoffem i jitterem, żeby po awarii dziesięć tysięcy urządzeń nie uderzyło w usługę w tej samej sekundzie.",[98,263,265],{"id":264},"obsługa-podatności-przez-lata","Obsługa podatności przez lata",[88,267,268],{},"Część II załącznika I dotyczy procesów. Dla każdego wydania potrzebujesz SBOM-u w powszechnie stosowanym formacie nadającym się do odczytu maszynowego, który obejmuje co najmniej zależności najwyższego poziomu. Podatności usuwasz bez zbędnej zwłoki, a jeśli jest to technicznie wykonalne, poprawki bezpieczeństwa wydajesz osobno od nowych funkcji. Regularnie testujesz bezpieczeństwo produktu. Kiedy poprawka jest już dostępna, publikujesz informację o tym, na czym polegała podatność, których produktów dotyczy, jak jest poważna i co powinni zrobić użytkownicy. Prowadzisz politykę skoordynowanego ujawniania podatności i podajesz publicznie kontakt, pod który można zgłaszać problemy, także w komponentach zewnętrznych zintegrowanych z twoim produktem. Aktualizacje trzeba dystrybuować w bezpieczny sposób, a aktualizacje bezpieczeństwa udostępniać bezpłatnie, razem z komunikatem, co użytkownicy mają zrobić.",[88,270,271],{},"W artykule 13 łatwo przeoczyć dwie liczby. Okres wsparcia musi wynosić co najmniej pięć lat, a dłużej, jeśli produkt ma być dłużej używany, i jego datę końcową, co najmniej z dokładnością do miesiąca i roku, trzeba podać w momencie zakupu. Każda opublikowana aktualizacja bezpieczeństwa musi potem pozostać dostępna przez co najmniej dziesięć lat albo przez resztę okresu wsparcia, w zależności od tego, który okres jest dłuższy. Jeśli serwer aktualizacji i klucze do podpisywania nie są zaplanowane na taki horyzont, czas to zmienić.",[98,273,275],{"id":274},"dokumenty-ocena-zgodności-i-oznakowanie-ce","Dokumenty, ocena zgodności i oznakowanie CE",[88,277,278],{},"Załącznik II wymienia, co muszą zawierać informacje dla użytkownika, od kontaktu do zgłaszania podatności i daty końca wsparcia po instrukcje bezpiecznej konfiguracji, aktualizacji i wycofania urządzenia z użytku. Załącznik VII opisuje dokumentację techniczną, która zbiera w jednym miejscu opis produktu, architekturę, procesy obsługi podatności, ocenę ryzyka, uzasadnienie długości okresu wsparcia, raporty z testów i deklarację zgodności. Jedno i drugie trzeba przechowywać przez dziesięć lat albo przez okres wsparcia, jeśli jest dłuższy.",[88,280,281],{},"Sposób wykazania zgodności zależy od kategorii produktu. Produkt z kategorii domyślnej, do której należy większość czujników, trackerów i sterowników, możesz ocenić sam w ramach kontroli wewnętrznej. Ważne produkty klasy I mogą skorzystać z tej ścieżki tylko wtedy, gdy w pełni stosują normy zharmonizowane, wspólne specyfikacje albo program certyfikacji. Normy zharmonizowane dla CRA są wciąż na etapie finalizacji, więc w praktyce wielu producentów produktów klasy I powinno zaplanować współpracę z jednostką notyfikowaną. Klasa II wymaga jej zawsze, a produkty krytyczne, takie jak bramki inteligentnych liczników, mogą potrzebować europejskiego certyfikatu. Przepisy dotyczące jednostek notyfikowanych stosuje się od czerwca 2026 i spodziewam się, że ich kalendarze zapełnią się na długo przed grudniem 2027. Na końcu jest deklaracja zgodności UE i oznakowanie CE, a u większości z nas CRA trafi do jednej deklaracji razem z dyrektywą w sprawie urządzeń radiowych.",[88,283,284],{},"Kary warto znać, nawet jeśli nikt nie zamierza ich płacić. Naruszenie zasadniczych wymagań albo obowiązków z artykułów 13 i 14 może kosztować do piętnastu milionów euro lub dwóch i pół procent światowego obrotu, w zależności od tego, która kwota jest wyższa.",[98,286,288],{"id":287},"od-czego-bym-zaczął","Od czego bym zaczął",[88,290,291],{},"Gdybym dziś odpowiadał za inżynierię w małej firmie sprzętowej, zacząłbym od zgłaszania, bo ten obowiązek już się stosuje, a dotyczy głównie ludzi i kont. Zarejestrowałbym firmę na platformie ENISA, ustalił, kto podejmuje decyzję o drugiej w nocy, sprawdził, które wersje firmware działają w których krajach, i uruchomił codzienne porównywanie SBOM-ów z listami aktywnie wykorzystywanych podatności.",[88,293,294],{},"Potem wziąłbym się za wszystko, co wymaga zmian w firmware albo w sprzęcie, bo to zajmuje całe cykle produktowe. Chodzi o secure boot, podpisane aktualizacje z ochroną przed rollbackiem, osobne dane uwierzytelniające dla każdego urządzenia, zablokowane porty debugowania i SBOM generowany przez build. Jeśli do zmieszczenia secure elementu albo zablokowania interfejsu debugowania potrzebna będzie nowa rewizja płytki, dużo taniej jest dowiedzieć się o tym w 2026 niż pod koniec 2027.",[88,296,297],{},"Dokumentację zostawiłbym na koniec, bo idzie znacznie szybciej, kiedy część inżynierska już istnieje. Ocena ryzyka pisana po podjęciu decyzji projektowych w większości spisuje powody, które i tak już miałeś. Dokumentacja techniczna składana z pipeline'u, który przy każdym wydaniu generuje SBOM-y i raporty z testów, to głównie linki.",[98,299,301],{"id":300},"checklista","Checklista",[88,303,304,305,308,309,313],{},"Wszystko to zebrałem w ",[92,306,307],{"href":219},"checkliście gotowości",". Trzy pytania o produkt dopasowują ją do twojej sytuacji, a potem każdą pozycję możesz oznaczyć jako zrobioną, w toku, do zrobienia albo niedotyczącą. Przy każdej jest odwołanie do artykułu lub załącznika, z którego pochodzi. Checklista działa w przeglądarce, odpowiedzi zostają na twoim urządzeniu, a na koniec dostajesz raport luk w Markdownie, z którym możesz pójść do zespołu. Jeśli nie masz jeszcze pewności, czy CRA w ogóle obejmuje twój produkt, zacznij od ",[92,310,312],{"href":311},"/pl/cra/scope-check","sprawdzenia zakresu",".",[88,315,316],{},"Nic z tego nie jest poradą prawną, a normy zharmonizowane, kiedy zostaną opublikowane, doprecyzują, jak spełniać poszczególne wymagania. Sama struktura obowiązków wynika jednak bezpośrednio z rozporządzenia i nie będzie się zmieniać. Jeśli twój zespół patrzy na tę listę i zastanawia się, od czego zacząć, chętnie pomogę.",{"title":191,"searchDepth":192,"depth":192,"links":318},[319,320,321,322,323,324,325],{"id":224,"depth":192,"text":225},{"id":234,"depth":192,"text":235},{"id":244,"depth":192,"text":245},{"id":264,"depth":192,"text":265},{"id":274,"depth":192,"text":275},{"id":287,"depth":192,"text":288},{"id":300,"depth":192,"text":301},"Przeszedłem przez Cyber Resilience Act punkt po punkcie i zebrałem obowiązki producenta w jedną checklistę. Czego wymaga od urządzenia IoT i od czego zacząć.","pl",{},"8 min czytania",{"title":211,"description":326},[11,12,13,14],"LsB7hF2DgMEdF75QXi816EXW2ZCZijUDL6O0XPNId2c",1792141329343]