FCC blokuje nowe zagraniczne roboty i falowniki

30 lipca 2026 roku szerzej opisano decyzję amerykańskiej Federal Communications Commission dotyczącą dwóch kategorii urządzeń połączonych z siecią: zaawansowanych robotów mobilnych oraz falowników energetycznych produkowanych za granicą. FCC dodała je do Covered List, co co do zasady blokuje wydawanie nowych autoryzacji sprzętowych potrzebnych do importu, marketingu i sprzedaży nowych modeli w USA.

Nie jest to nakaz wyłączenia już działających robotów ani falowników. Decyzja nie dowodzi też trwającej kampanii włamań. Jest prewencyjnym ruchem dotyczącym łańcucha dostaw, zdalnego sterowania, zbierania danych i wpływu dużej floty urządzeń na infrastrukturę krytyczną.

Co dokładnie zdecydowała FCC

Oficjalny fact sheet FCC z 28 lipca potwierdza dodanie do Covered List:

zagranicznie produkowanych „advanced robotic devices”, w tym mobilnych robotów humanoidalnych i czworonożnych;
zagranicznie produkowanych, połączonych z siecią falowników energetycznych.

Decyzja wynika z ocen międzyagencyjnego organu administracji USA, który uznał te kategorie za stwarzające niedopuszczalne ryzyko dla bezpieczeństwa narodowego lub bezpieczeństwa osób w USA.

Najważniejsze ograniczenia zakresu:

dotyczy nowych modeli, które potrzebują autoryzacji FCC;
wcześniej zatwierdzone modele mogą nadal być sprzedawane;
urządzenia już kupione mogą nadal działać;
decyzja nie dotyczy zakupów ani użycia przez rząd federalny;
możliwe jest Conditional Approval właściwego organu;
producenci mogą nadal publikować kwalifikujące się poprawki bezpieczeństwa i kompatybilności dla wcześniej autoryzowanego sprzętu.

Publikacja z 30 lipca zwróciła uwagę na istotny waiver: co najmniej do 1 stycznia 2029 roku dozwolone mają być zmiany oprogramowania i firmware’u służące łataniu luk oraz zgodności z systemami operacyjnymi.

„Zagraniczny” nie oznacza jednej wskazanej marki

Dokument nie tworzy listy konkretnych producentów ani jednego kraju. W zastosowanych ocenach „foreign-produced” oznacza urządzenie, które nie kwalifikuje się jako domestic end product według standardu Buy American w 48 CFR 25.101(a).

To ważne, ponieważ nagłówek „FCC zakazuje chińskich robotów” byłby zbyt szeroki i nieprecyzyjny. Uzasadnienia cytują przykłady producentów i incydentów, ale operacyjny zakres wynika z definicji produkcji i parametrów technicznych, nie wyłącznie z logo.

Producenci mogą wystąpić o Conditional Approval. W przypadku robotów decyzję może wydać Department of War, a dla falowników Department of War lub Department of Homeland Security. Według dokumentów wnioski powinny zostać złożone do 1 stycznia 2028 roku.

Jaki robot znajduje się w definicji

Nie każdy odkurzacz, ramię w fabryce czy dron automatycznie wchodzi w zakres. Definicja obejmuje mobilne urządzenie mechaniczne, które:

porusza się po ziemi;
potrafi nawigować lub omijać przeszkody;
może działać z dala od operatora na podstawie komend lub danych z sensorów;
waży ponad 4,4 funta, czyli około 2 kg, razem z odpowiednią stacją lub dockiem;
ma czujnik środowiskowy;
obsługuje komunikację przewodową lub bezprzewodową co najmniej 200 kb/s w jednym kierunku;
uruchamia lokalnie lub zdalnie software sterujący ruchem, percepcją, zbieraniem danych albo zdalnym dowodzeniem.

Definicja oprogramowania obejmuje firmware oraz wagi modeli AI/ML. Oznacza to, że bezpieczeństwo robota nie kończy się na systemie operacyjnym. Aktualizacja modelu percepcji, usługa chmurowa, aplikacja operatora i firmware sterownika są częściami tego samego łańcucha.

Co zostało wyłączone

Dokument wyłącza między innymi:

połączone z siecią pojazdy drogowe;
urządzenia poruszające się wyłącznie po torach;
bezzałogowe statki powietrzne;
pojazdy podwodne;
urządzenia medyczne i mobilnościowe regulowane przez FDA;
stacjonarne ramiona przemysłowe, w tym konstrukcje SCARA, gantry i delta.

Wyłączenie z tej konkretnej decyzji nie oznacza braku cyberryzyka. Te kategorie podlegają innym regulacjom i modelom oceny.

Jak FCC definiuje falownik

Falownik przekształca prąd stały na przemienny albo odwrotnie i zawiera komponenty do zdalnej komunikacji, sterowania, pomiaru, zbierania danych lub monitorowania. W praktyce dotyczy to elementów fotowoltaiki, magazynów energii, ładowania i innych zasobów opartych na elektronice mocy.

Pojedyncze urządzenie ma ograniczony wpływ. Ryzyko rośnie, gdy tysiące lub setki tysięcy falowników:

korzystają z jednego backendu producenta;
mają wspólny mechanizm aktualizacji;
przyjmują zdalne polecenia;
raportują dane operacyjne;
używają tych samych kluczy lub kont serwisowych;
mogą jednocześnie zmienić tryb pracy.

Wtedy podatność aplikacji chmurowej lub łańcucha aktualizacji staje się problemem systemowym, a nie tylko lokalną awarią.

Jakie ryzyka wskazano dla robotów

Ocena bezpieczeństwa robotów przywołuje raporty o:

dostępie do obrazu kamer, mikrofonu i map pomieszczeń robotów domowych;
czterech lukach związanych z Bluetooth Low Energy w badaniu UniPwn;
możliwości wykonania poleceń z uprawnieniami root na wybranych modelach;
potencjalnym rozprzestrzenianiu przez BLE na urządzenia w pobliżu;
zdalnym sterowaniu robotem przez usługę chmurową po uzyskaniu właściwego klucza API.

Nie oznacza to, że każdy robot w Covered List ma każdą z tych luk. Przykłady uzasadniają kategorię ryzyka: mobilne urządzenie ma sensory, napęd, łączność i zdalne zarządzanie, więc kompromitacja może naruszyć zarówno dane, jak i bezpieczeństwo fizyczne.

Jakie ryzyka wskazano dla falowników

Materiały odwołują się między innymi do badania Forescout SUN:DOWN, które opisało 46 luk w produktach Sungrow, SMA i Growatt. Badacze modelowali wpływ manipulacji dużą flotą i możliwość destabilizacji sieci.

Trzeba zachować granicę między symulacją a incydentem. Badanie nie potwierdza, że opisana destabilizacja została faktycznie wywołana przez napastnika. Pokazuje techniczną możliwość i skalę konsekwencji przy odpowiednich warunkach.

Ocena przywołuje również ryzyka opisane przez Idaho National Laboratory, analizę ERCOT dotyczącą szybkiej utraty stabilności w scenariuszu skrajnym oraz przypadek zdalnego wyłączenia falowników przez zagranicznego producenta po sporze z amerykańskim dystrybutorem. Producent nie został w tym dokumencie nazwany.

Dlaczego aktualizacje nadal muszą być dozwolone

Covered List ogranicza autoryzację nowego sprzętu, ale całkowite zablokowanie zmian firmware’u zwiększyłoby ryzyko dla już wdrożonych urządzeń. Waiver dla poprawek bezpieczeństwa jest więc kluczowy.

Organizacja powinna odróżnić:

poprawkę zamykającą lukę;
zmianę kompatybilności;
nową funkcję zdalnego sterowania;
zmianę backendu i telemetrii;
aktualizację modelu AI wpływającą na zachowanie;
wymianę komponentu kryptograficznego.

Każda „aktualizacja” nie ma tego samego profilu. Wrażliwe środowisko powinno wymagać podpisu, manifestu zmian, możliwości rollbacku, testu offline i udokumentowanego pochodzenia.

Co ta decyzja znaczy dla Polski i UE

Decyzja FCC nie obowiązuje bezpośrednio polskich firm ani nie tworzy europejskiego zakazu sprzedaży. Może być jednak użytecznym sygnałem do oceny ryzyka dostawców.

Polska organizacja zarządzająca robotami lub energetyką powinna zapytać:

kto kontroluje backend chmurowy;
gdzie znajdują się dane i logi;
czy urządzenie działa bez chmury producenta;
czy zdalne wyłączenie wymaga zgody właściciela;
jak rozdzielone są role serwisowe;
czy producent publikuje SBOM i advisory;
czy klucze są unikalne dla urządzeń;
jak długo zapewniane są poprawki;
co dzieje się po zakończeniu wsparcia lub upadku dostawcy;
czy można niezależnie zweryfikować firmware i aktualizację modelu.

To element oceny łańcucha dostaw, nie automatyczna dyskwalifikacja każdego zagranicznego produktu.

Model zagrożeń dla robota

Robot łączy świat cybernetyczny i fizyczny. Model powinien obejmować:

aplikację operatora;
konto i MFA;
API producenta;
backend chmurowy;
kanał aktualizacji;
firmware kontrolera;
system operacyjny;
model percepcji;
sensory i zapis danych;
łączność lokalną, w tym Wi-Fi i BLE;
mechanizm zatrzymania awaryjnego;
fizyczny dostęp serwisowy.

Najgroźniejszy błąd nie zawsze jest RCE. Nieprawidłowa autoryzacja API może wystarczyć do oglądania map, podglądu sensorów lub wysłania polecenia ruchu.

Model zagrożeń dla falownika

W falowniku priorytetem jest równoczesny wpływ na dostępność i parametry sieci. Należy ocenić:

lokalny panel i domyślne hasła;
modem lub gateway;
protokoły telemetryczne;
API chmurowe;
konto instalatora;
certyfikaty i klucze;
podpis aktualizacji;
komendy grupowe;
limit szybkości zmian;
zachowanie fail-safe po utracie chmury;
segmentację od systemów OT;
lokalną możliwość odzyskania sterowania.

Mechanizm grupowego zarządzania powinien mieć ograniczenia uniemożliwiające niekontrolowaną zmianę całej floty w jednej chwili. Ważne są progi, stopniowanie wdrożeń i niezależny monitoring parametrów.

Działania techniczne dla właściciela urządzeń

zinwentaryzuj modele, firmware, backend i właściciela konta;
oddziel roboty i falowniki od sieci użytkowników;
ogranicz egress do udokumentowanych usług;
wymuś unikalne poświadczenia i phishing-resistant MFA;
wyłącz nieużywane interfejsy lokalne;
przechowuj logi komend oraz zmian firmware’u;
alarmuj na masowe polecenia i nową geografię logowania;
testuj tryb offline i odzyskanie lokalnej kontroli;
utrzymuj bezpieczny proces aktualizacji;
przygotuj procedurę izolacji bez tworzenia zagrożenia fizycznego.

W robotyce nie wolno reagować przez nagłe odcięcie zasilania, jeśli może to spowodować ruch, upadek ładunku lub utratę hamowania. Procedura cyber musi być zgodna z funkcjonalnym bezpieczeństwem urządzenia.

Działania dla zakupów i bezpieczeństwa

Umowa z dostawcą powinna obejmować:

czas wsparcia;
SLA poprawek krytycznych;
zgłaszanie incydentów;
prawo do logów;
SBOM;
kontrolę podwykonawców;
lokalizację danych;
proces ujawniania podatności;
możliwość migracji backendu;
bezpieczne wycofanie urządzenia;
zakaz współdzielonych sekretów serwisowych.

Więcej o ocenie komponentów i dostawców piszemy w przewodniku o atakach na łańcuch dostaw oprogramowania oraz SBOM, CycloneDX i VEX.

Test odbiorczy przed podłączeniem do floty

Przed zakupem reprezentatywny egzemplarz powinien przejść test w odizolowanej sieci. Zespół zapisuje wszystkie domeny i protokoły, sprawdza zmianę domyślnych poświadczeń, weryfikuje podpis aktualizacji oraz zachowanie po utracie internetu i chmury. Osobno należy ustalić, czy konto instalatora zachowuje dostęp po przekazaniu urządzenia klientowi.

Dla robota test obejmuje ograniczenie prędkości, bezpieczne zatrzymanie i odzyskanie lokalnego sterowania. Dla falownika — granice zdalnych nastaw, tempo poleceń grupowych, reakcję na utratę backendu i zgodność cyberprocedury z wymaganiami sieci elektroenergetycznej. Wyniki muszą trafić do kryteriów akceptacji, nie tylko do raportu bezpieczeństwa.

Źródła a wnioski Breachroad

FCC potwierdza zakres Covered List, wpływ na nowe modele, brak wpływu na już kupione urządzenia oraz mechanizm Conditional Approval. Uzasadnienia przywołują konkretne badania, ale nie ogłaszają jednej aktywnej kampanii włamań przeciwko wszystkim robotom lub falownikom.

Rekomendacje techniczne, umowne i dotyczące Polski są wnioskami Breachroad. Decyzja USA jest inspiracją dla threat modelu, nie obowiązującym w UE zakazem.

Audyt bezpieczeństwa chmury i infrastruktury może objąć backend, API, konta, segmentację i proces aktualizacji urządzeń. Szkolenia cyberbezpieczeństwa dla organizacji pomagają zakupom, inżynierii i SOC rozumieć wspólną odpowiedzialność. Dodatkowy kontekst OT znajdziesz w materiale o atakach na wodociągi i infrastrukturę.