Sicurezza IoT: la guida dell'ingegnere hardware

Quello che i concorrenti non vi diranno sulla sicurezza IoT

La maggior parte delle guide sulla sicurezza IoT si concentra sulla sicurezza IT applicata all’IoT: firewall, patching, controllo degli accessi, Zero Trust. Queste misure sono necessarie ma insufficienti per i sistemi industriali.

Ecco cosa tralasciano:

Cosa coprono i concorrenti ❌	Cosa conta davvero ✅
“Cambiate le password di default”	Hardware Root of Trust: le password possono essere estratte dalla flash; i Secure Element non possono essere letti
”Usate la cifratura”	Ciclo di vita della gestione delle chiavi: dove vengono generate, memorizzate, ruotate e revocate le chiavi?
”Mantenete il software aggiornato”	Aggiornamenti firmware autenticati: come si impedisce a un aggiornamento malevolo di rendere inutilizzabili (brick) 10.000 dispositivi?
”Segmentate la vostra rete”	Protezione fisica dalla manomissione: cosa succede quando qualcuno ha accesso fisico al dispositivo?
”Eseguite un antivirus”	Non esiste un antivirus per i sistemi embedded: la sicurezza deve essere progettata nell’hardware
”Monitorate le anomalie”	Un dispositivo compromesso può mentire: solo l’attestazione hardware dimostra l’integrità del dispositivo

Questa guida affronta la sicurezza IoT a partire dall’hardware, la prospettiva che conta quando si progettano i prodotti, non solo quando li si implementa.

Il costo reale di sbagliare

I fallimenti della sicurezza dell’IoT industriale non sono astratti: hanno conseguenze quantificabili:

Incidente	Impatto	Causa principale
Triton/TRISIS (2017)	Tentata esplosione di un impianto petrolchimico saudita	Malware mirato ai sistemi strumentati di sicurezza (SIS)
Colonial Pipeline (2021)	4,4 mln $ di riscatto, fornitura di carburante negli USA interrotta per 6 giorni	Credenziale VPN compromessa, nessuna MFA sull’accesso OT
Telecamere Verkada (2021)	150.000 telecamere compromesse (Tesla, ospedali, carceri)	Credenziali admin hardcoded nel firmware
Acquedotto di Oldsmar (2021)	Tentato avvelenamento dell’approvvigionamento idrico (idrossido di sodio 100×)	Accesso remoto allo SCADA senza autenticazione
MOVEit (2023)	Oltre 2.500 organizzazioni violate	Appliance di trasferimento file non aggiornata (unpatched)

Filo conduttore comune: ogni grande violazione IIoT ha sfruttato la mancanza di sicurezza hardware, il software non aggiornato o un controllo degli accessi inadeguato. La sicurezza basata solo sul software ha fallito in ogni caso.

Costo medio di una violazione di sicurezza industriale: 4,7 milioni di € (IBM Cost of a Data Breach 2025). Per le infrastrutture critiche, il costo può includere la safety delle persone.

Lo stack dell’architettura di sicurezza

Mettere in sicurezza un dispositivo IoT industriale richiede una difesa a ogni livello:

┌─────────────────────────────────────────────────────────────┐
│  SICUREZZA CLOUD / BACKEND                                  │
│  Autenticazione API, gestione dei certificati               │
│  Gestione del parco dispositivi, registrazione degli audit  │
├─────────────────────────────────────────────────────────────┤
│  SICUREZZA APPLICATIVA                                      │
│  Validazione degli input, programmazione sicura, SBOM       │
│  Archiviazione cifrata, controllo degli accessi             │
├─────────────────────────────────────────────────────────────┤
│  SICUREZZA DELLE COMUNICAZIONI                              │
│  TLS reciproco, DTLS, MQTT cifrato                          │
│  Certificate pinning, rotazione delle chiavi                │
├─────────────────────────────────────────────────────────────┤
│  SICUREZZA DEL FIRMWARE                                     │
│  Aggiornamenti firmati, protezione dal rollback             │
│  Bootloader sicuro, firma del codice                        │
├─────────────────────────────────────────────────────────────┤
│  SICUREZZA OS / RTOS                                        │
│  Protezione della memoria, separazione dei privilegi        │
│  API di archiviazione sicura, watchdog                      │
├─────────────────────────────────────────────────────────────┤
│  ★ SICUREZZA HARDWARE (base del sistema) ★                  │
│  Secure Element / TPM, ROM per secure boot                  │
│  RNG hardware, rilevamento delle manomissioni, PUF          │
│  Chiavi in eFuse, blocco delle porte di debug               │
└─────────────────────────────────────────────────────────────┘

Principio chiave: la sicurezza si propaga verso l’alto. Se il livello hardware è compromesso, ogni livello sopra di esso è compromesso. Per questo la sicurezza hardware è la base su cui progettare il sistema fin dall’inizio.

Best practice 1: Hardware Root of Trust

La decisione più critica nella progettazione della sicurezza IoT è stabilire un Hardware Root of Trust: un componente immutabile e resistente alla manomissione che funge da àncora di sicurezza per l’intero sistema.

TPM vs Secure Element vs integrato nell’MCU: quale usare?

Caratteristica	TPM discreto	Secure Element	Integrato nell’MCU (TrustZone/PSA)
Standard	TCG TPM 2.0 (ISO 11889)	CC EAL5+/EAL6+	PSA Certified (Level 1-3)
Memorizzazione chiavi	Chiavi RSA/ECC, sealed storage	Chiavi ECC/AES, certificati X.509	Secure enclave isolato
Resistenza alla manomissione	Media (chip discreto)	Alta (progettato per attacchi fisici)	Bassa-Media (die condiviso)
Costo	2-8 € per unità	0,50-3 € per unità	0 € (integrato nell’MCU)
Prestazioni crypto	Moderate (collo di bottiglia del bus I2C/SPI)	Moderate	Veloci (on-die)
Ideale per	Dispositivi di classe PC/server, sistemi Linux	Dispositivi IoT, smart card, ambienti vincolati	Progetti MCU sensibili al costo
Chip di esempio	Infineon SLB 9670, Microchip ATECC608B	NXP SE050, Infineon OPTIGA Trust M	STM32U5 (TrustZone), nRF5340

Quando usare quale

• Sensore IoT a batteria → TrustZone integrato nell’MCU (costo più basso, accettabile per PSA Level 2)
• Gateway industriale → TPM 2.0 discreto (standard TCG, verificabile, supporto Linux)
• Terminale di pagamento o infrastruttura critica → Secure Element (CC EAL5+, massima resistenza alla manomissione)
• Sistema basato su FPGA → cifratura del bitstream FPGA + Secure Element esterno per la memorizzazione delle chiavi

Checklist di implementazione

□ Identità univoca del dispositivo (certificato X.509 per dispositivo, non per lotto)
□ Chiave privata generata sul chip (non lascia mai il Secure Element)
□ RNG hardware per generare le chiavi (non PRNG software)
□ Contatore monotono per la protezione dal rollback
□ Porte di debug (JTAG/SWD) disabilitate nel firmware di produzione
□ Bit di protezione impostati per impedire la lettura della flash
□ GPIO di rilevamento delle manomissioni (facoltativo per applicazioni ad alta sicurezza)

Per pattern di implementazione dettagliati, consultate la pagina del nostro servizio Embedded Security & IoT.

Best practice 2: catena di Secure Boot

Una catena di Secure Boot garantisce che sul dispositivo venga eseguito solo codice autenticato e non manomesso, dall’accensione fino all’applicazione:

Accensione
    ↓
 1. Boot ROM (immutabile, nel silicio)
    → Verifica la firma del bootloader con la chiave pubblica memorizzata in OTP
    ↓
 2. Bootloader (primo stadio aggiornabile)
    → Verifica la firma dell'immagine firmware (ECDSA P-256 o Ed25519)
    → Controlla il contatore anti-rollback (impedisce gli attacchi di downgrade)
    ↓
 3. Firmware / RTOS
    → Verifica l'integrità dell'applicazione
    → Inizializza l'archiviazione sicura
    ↓
 4. Applicazione
    → Stabilisce una connessione TLS con il backend
    → Avvia il normale funzionamento

Errori comuni nel Secure Boot

Errore	Conseguenza	Correzione
Memorizzare la chiave di firma insieme al firmware	L’attaccante estrae la chiave e firma firmware malevolo	Chiave solo nel Secure Element, mai nella flash
Nessuna protezione dal rollback	L’attaccante installa vecchio firmware vulnerabile	Contatore monotonico nei fuse OTP
Verificare solo il primo stadio	Gli stadi successivi possono essere modificati senza essere rilevati	Catena di fiducia: ogni stadio verifica il successivo
Debug port lasciata aperta in produzione	JTAG/SWD aggira l’intera catena di boot	Disabilitazione del JTAG tramite fuse prima del deployment
Usare solo SHA-256 (nessuna firma)	L’hash può essere ricalcolato per il firmware modificato	Usare la verifica della firma ECDSA o Ed25519

Secure Boot specifico per FPGA

Le FPGA hanno requisiti di Secure Boot unici perché l’intera configurazione hardware viene caricata all’accensione:

1. Cifratura del bitstream — cifratura AES-256 del file di configurazione FPGA
2. Autenticazione del bitstream — verifica della firma RSA/ECDSA prima del caricamento
3. Memorizzazione delle chiavi — eFUSE o RAM con backup a batteria per le chiavi di cifratura
4. Fallback — bitstream golden/di ripristino in caso di fallimento dell’autenticazione primaria
5. Riconfigurazione parziale — aggiornare solo porzioni dell’FPGA senza ricaricare tutto

Le FPGA sia AMD/Xilinx sia Intel/Altera supportano nativamente queste funzionalità. I nostri FPGA Design Services includono l’architettura di sicurezza fin dall’inizio di ogni progetto.

Best practice 3: comunicazioni cifrate

Ogni percorso dati in un sistema IoT deve essere cifrato e autenticato:

Selezione del protocollo per l’IoT industriale

Protocollo	Sicurezza	Overhead	Ideale per	Raccomandazione
MQTT + TLS 1.3	Forte	Medio (TCP + TLS)	Dispositivi connessi al cloud, telemetria	✅ Scelta predefinita per dispositivi IP-capable
MQTT-SN + DTLS	Forte	Inferiore (basato su UDP)	Dispositivi vincolati, reti con perdite	✅ Adatto per LoRaWAN/NB-IoT
CoAP + DTLS	Forte	Basso	Dispositivi vincolati RESTful	✅ Alternativa a MQTT per request/response
OPC UA	Forte (integrata)	Alto	Automazione industriale, SCADA	✅ Standard per il reparto produttivo
Modbus TCP	❌ Nessuna nativamente	Basso	Industriale legacy	⚠️ Incapsulare in VPN o tunnel TLS
BLE	Media (AES-CCM)	Basso	Sensori a corto raggio	⚠️ Adeguato per dati non critici
LoRaWAN	AES-128 (integrata)	Molto basso	Sensori LPWAN	✅ Accettabile per dati dei sensori

TLS reciproco: perché il TLS solo lato server non basta

L’HTTPS/TLS standard autentica solo il server. Nell’IoT, anche il dispositivo deve autenticarsi presso il server (TLS reciproco / mTLS):

TLS standard:
  Dispositivo → "Mi fido del server" (verifica il certificato del server)
  Server → "Non conosco la tua identità" (accetta qualsiasi client)

TLS reciproco:
  Dispositivo → "Mi fido del server" (verifica il certificato del server)
  Server → "Dimostra di essere un dispositivo autentico" (verifica il certificato del dispositivo)
  Dispositivo → Presenta il certificato X.509 dal Secure Element
  Server → Verifica completata: connessione stabilita

Perché l’mTLS è importante: senza l’autenticazione del dispositivo, un attaccante può impersonare un dispositivo, iniettare dati falsi dei sensori o esfiltrare comandi destinati a dispositivi legittimi.

Rotazione delle chiavi e ciclo di vita dei certificati

Produzione → Provisioning del dispositivo con il certificato iniziale
      ↓
 Messa in servizio → Registrazione del certificato sulla piattaforma IoT
      ↓
 Funzionamento → Rotazione dei certificati ogni 1-2 anni
      ↓
 Dismissione → Revoca del certificato e cancellazione dei dati del dispositivo

Le chiavi non dovrebbero mai essere condivise tra dispositivi. Ogni dispositivo riceve una coppia di chiavi univoca generata nel proprio Secure Element durante la produzione.

Best practice 4: aggiornamenti firmware sicuri (OTA)

La capacità di aggiornare i dispositivi implementati è al tempo stesso un requisito di sicurezza e un rischio di sicurezza. Un meccanismo di aggiornamento compromesso fornisce agli attaccanti accesso root all’intero parco dispositivi.

Requisiti di sicurezza per gli aggiornamenti OTA

Requisito	Scopo	Implementazione
Code signing	Verificare l’autenticità dell’aggiornamento	Firma ECDSA-P256 o Ed25519
Cifratura	Impedire il reverse engineering del firmware	Cifratura AES-256 del pacchetto di aggiornamento
Protezione dal rollback	Impedire il downgrade a una versione vulnerabile	Contatore monotonico in OTP/Secure Element
Aggiornamento atomico	Impedire il bricking da aggiornamento interrotto	Schema a partizioni A/B o aggiornamenti delta
Verifica della versione	Garantire il firmware corretto per il dispositivo corretto	Verifica dell’hardware ID + versione prima dell’applicazione
Audit trail	Tracciare lo stato degli aggiornamenti sull’intero parco	Logging di backend dello stato di aggiornamento per dispositivo

Architettura di aggiornamento A/B

Organizzazione della flash:
 ┌──────────────────┐
 │    Bootloader    │  Verifica la partizione attiva
 ├──────────────────┤
 │   Partizione A   │  ← Versione attualmente in esecuzione (v2.1)
 ├──────────────────┤
 │   Partizione B   │  ← Qui viene scritto il nuovo aggiornamento (v2.2)
 ├──────────────────┤
 │ Memoria protetta │  Chiavi, certificati, configurazione
 └──────────────────┘

 Processo di aggiornamento:
 1. Scaricare v2.2 nella partizione B (mentre v2.1 è in esecuzione)
 2. Verificare la firma di v2.2
 3. Controllare il contatore anti-rollback (v2.2 > v2.1 ✓)
 4. Contrassegnare la partizione B come "in attesa"
 5. Riavviare → il bootloader prova la partizione B
 6. Avvio riuscito → contrassegnare B come "attiva"
 7. Avvio non riuscito → tornare automaticamente alla partizione A

Questo non è opzionale: il Cyber Resilience Act dell’UE impone aggiornamenti firmware autenticati per tutti i prodotti connessi venduti nell’UE a partire dal 2027. Consultate la nostra Checklist di conformità al CRA.

Best practice 5: segmentazione di rete e Zero Trust

Il modello Purdue per le reti industriali

Le reti industriali dovrebbero seguire una segmentazione a livelli:

Livello 5: azienda     │ ERP, email, internet
 ───── DMZ ────────────┤ Firewall + IDS
 Livello 4: gestione   │ MES, historian, reportistica
 ───── DMZ ────────────┤ Firewall industriale
 Livello 3: operazioni │ HMI, SCADA, ingegneria
 ─────────────────────┤ Switch gestito + ACL
 Livello 2: controllo  │ PLC, DCS, RTU
 ─────────────────────┤ Isolamento fisico
 Livello 1: campo      │ Sensori, attuatori, azionamenti
 Livello 0: processo   │ Apparecchiature fisiche

Zero Trust per l’OT — implementazione pratica

Lo Zero Trust negli ambienti industriali non significa “autenticare tutto con la MFA”: alcuni dispositivi non hanno nemmeno uno schermo. Lo Zero Trust pratico per l’OT significa:

1. Micro-segmentazione di rete — ogni dispositivo o gruppo di dispositivi nella propria VLAN
2. Identità del dispositivo — autenticazione basata su certificati X.509 (non password)
3. Privilegio minimo — i dispositivi possono comunicare solo con il proprio controllore, non tra loro
4. Traffico est-ovest cifrato — comunicazione tra dispositivi cifrata anche all’interno della rete OT
5. Monitoraggio continuo — rilevamento delle anomalie sui pattern di traffico (non ispezione del payload, che compromette il real-time)
6. Nessuna fiducia implicita — un dispositivo autenticato 5 minuti fa deve riautenticarsi se il suo comportamento cambia

Best practice 6: sicurezza fisica (il livello dimenticato)

La maggior parte delle guide sulla sicurezza IoT si ferma alla rete. Ma i dispositivi industriali sono implementati in luoghi fisicamente accessibili: reparti produttivi, armadi di utility, installazioni all’aperto.

Superficie di attacco fisica

Vettore di attacco	Rischio	Mitigazione
Debug port (JTAG/SWD)	Estrazione completa del firmware, dump delle chiavi	Disabilitazione tramite fuse, copertura con resina epossidica in produzione
Flash readout	Reverse engineering del firmware	Bit di protezione in lettura della flash + firmware cifrato
Bus sniffing (I2C/SPI verso il Secure Element)	Estrazione delle chiavi durante il funzionamento	Usare comunicazione su bus cifrata o integrazione on-die
Side-channel (analisi della potenza, emanazione EM)	Estrazione delle chiavi dalle operazioni crypto	Crypto a tempo costante, contromisure hardware
Fault injection (voltage glitching, laser)	Aggiramento del Secure Boot, salto dell’autenticazione	Verifiche ridondanti, rilevatori di glitch, Secure Element con protezione FI
Sostituzione del dispositivo	Sostituire un dispositivo compromesso	Attestazione del dispositivo + fleet management

Misure di sicurezza a livello di PCB

Per i design industriali ad alta sicurezza, considerate:

• Involucri a prova di manomissione (tamper-evident) — sigilli fisici che mostrano se il dispositivo è stato aperto
• Tamper-responsive — mesh attiva sopra i componenti sensibili, cancella le chiavi in caso di violazione
• Conformal coating — protegge le piste del PCB dalle sonde
• Package BGA — i componenti ball grid array sono più difficili da sondare rispetto ai QFP
• Composto di potting — incapsula i componenti critici per la sicurezza nella resina epossidica

Conformità normativa UE

Cyber Resilience Act dell’UE (CRA) — requisiti hardware

Il CRA (in vigore dal 2027) impone obblighi specifici ai produttori di hardware:

Requisito CRA	Implementazione hardware
Sicurezza fin dalla progettazione	Hardware Root of Trust, Secure Boot dalla ROM
Gestione delle vulnerabilità	Capacità di aggiornamento OTA, processo PSIRT
SBOM (Software Bill of Materials)	Includere componenti firmware, versione del bootloader, librerie crypto
Nessuna vulnerabilità sfruttabile nota al rilascio	Test di sicurezza pre-rilascio, penetration testing
Aggiornamenti autenticati per tutto il ciclo di vita	OTA firmato, protezione dal rollback, partizionamento A/B
Segnalazione delle vulnerabilità attivamente sfruttate entro 24h	Piano di risposta agli incidenti, monitoraggio del parco dispositivi

IEC 62443 — sicurezza dell’automazione industriale

Lo standard internazionale per la cibersicurezza industriale definisce i Security Level (SL):

Livello	Significato	Requisiti hardware
SL 1	Protezione contro violazioni occasionali	Protezione con password, controllo degli accessi di base
SL 2	Protezione contro violazioni intenzionali con risorse limitate	Identità univoca, firmware firmato, TLS
SL 3	Protezione contro attacchi sofisticati con risorse moderate	Hardware Root of Trust, tamper detection, mTLS
SL 4	Protezione contro attacchi a livello statale con risorse estese	Secure Element (EAL5+), risposta attiva alla manomissione, verifica formale

Per i progetti che puntano a IEC 62443 SL 3+, la progettazione della sicurezza hardware deve essere incorporata fin dalla fase di architettura. Consultate la nostra Guida alla conformità UE.

ETSI EN 303 645 — sicurezza dell’IoT di consumo

Lo standard di base europeo per l’IoT di consumo impone:

• Nessuna password di default universale
• Implementare strumenti per gestire le segnalazioni di vulnerabilità
• Mantenere il software aggiornato
• Memorizzare in modo sicuro i parametri di sicurezza sensibili
• Comunicare in modo sicuro
• Ridurre al minimo le superfici di attacco esposte

Verifica e test di sicurezza

Checklist di test di sicurezza pre-produzione

□ Penetration test (estrazione del firmware, accesso alle porte di debug)
□ Fuzzing (parser dei protocolli, gestione degli aggiornamenti firmware)
□ Analisi side-channel (se vengono gestite chiavi di alto valore)
□ Prove di aggiramento del secure boot (glitching, fault injection)
□ Prove di validazione dei certificati (scaduti, revocati, CA errata)
□ Prove degli aggiornamenti OTA (rollback, interruzione, corruzione)
□ Prove di sicurezza radio (se wireless: BLE, Wi-Fi, LoRaWAN)
□ Prove di accesso fisico (JTAG, lettura della flash, intercettazione dei bus)
□ Verifica della conformità (CRA, IEC 62443, ETSI EN 303 645)

Strumenti per il test di sicurezza embedded

Strumento	Scopo	Costo
Ghidra	Reverse engineering del firmware	Gratuito (open-source NSA)
Binwalk	Estrazione e analisi del firmware	Gratuito
ChipWhisperer	Analisi side-channel e glitching	300-3.000 €
Analizzatore logico (Saleae)	Sniffing del protocollo su bus	150-1.500 €
Debugger JTAG (J-Link)	Test di accesso alla debug port	50-1.000 €
AFL/LibFuzzer	Fuzzing dei protocolli	Gratuito
OpenSSL s_client	Test della configurazione TLS	Gratuito

Domande frequenti

Qual è il rischio di sicurezza IoT più grande?

Il rischio più grande è l’assenza di un Hardware Root of Trust. Senza di esso, il firmware può essere estratto e clonato, le chiavi di cifratura possono essere lette dalla memoria flash e il Secure Boot può essere aggirato. La sicurezza basata solo sul software può sempre essere sconfitta con l’accesso fisico al dispositivo. Un Secure Element da 1 € elimina la classe di attacchi più impattante.

Quanto incide la sicurezza IoT sul costo del prodotto?

Uno stack di sicurezza di base (Secure Element + Secure Boot + OTA cifrato) aggiunge 1-5 € per unità di costo componenti e 10.000-30.000 € di tempo di sviluppo. Confrontate questo dato con il costo medio di una violazione industriale di 4,7 milioni di €. La sicurezza IoT non è un centro di costo: è mitigazione del rischio con un ROI quantificabile.

I dispositivi IoT esistenti possono essere messi in sicurezza retroattivamente?

Parzialmente. È possibile aggiungere protezioni a livello di rete (segmentazione, monitoraggio, VPN) ai dispositivi già implementati. Ma la sicurezza a livello di dispositivo (Secure Boot, Hardware Root of Trust) non può essere aggiunta dopo la produzione: deve essere progettata fin dall’inizio. Per questo le decisioni sull’architettura di sicurezza devono essere prese all’inizio del processo di sviluppo V-Model, non alla fine.

Qual è la differenza tra sicurezza IT e sicurezza OT?

La sicurezza IT dà priorità alla riservatezza (protezione dei dati). La sicurezza OT dà priorità alla disponibilità e alla safety (mantenere i sistemi operativi e le persone al sicuro). In ambito OT, una patch di sicurezza che causa 5 minuti di fermo non pianificato può costare più della vulnerabilità che corregge. Per questo la sicurezza OT richiede una gestione attenta del cambiamento, patch testate e spesso soluzioni a livello hardware che non richiedono riavvii.

In cosa differisce la IEC 62443 dal CRA dell’UE?

La IEC 62443 è uno standard internazionale volontario per la sicurezza dell’automazione industriale, ampiamente adottato nel settore manifatturiero. Il CRA dell’UE è un regolamento obbligatorio per tutti i prodotti con elementi digitali venduti nell’UE. Sono complementari: la IEC 62443 fornisce indicazioni tecniche dettagliate per l’implementazione; il CRA fornisce l’obbligo legale di implementare la sicurezza. I prodotti certificati IEC 62443 SL 2+ soddisferanno probabilmente la maggior parte dei requisiti del CRA.

Le FPGA necessitano di una sicurezza diversa rispetto agli MCU?

Sì. Le FPGA presentano superfici di attacco uniche perché l’intera configurazione hardware (bitstream) viene caricata all’accensione. Differenze chiave: 1) il bitstream deve essere cifrato (AES-256) e autenticato (RSA/ECDSA), 2) le chiavi di configurazione devono essere memorizzate in eFUSE o in RAM con backup a batteria, 3) anche la riconfigurazione parziale deve essere autenticata e 4) il fabric FPGA stesso può implementare funzioni di sicurezza (crypto hardware, PUF) che gli MCU non possono fornire. Consultate i nostri servizi di progettazione della sicurezza FPGA.

Come Inovasense mette in sicurezza l’IoT industriale

La sicurezza è integrata in ogni progetto che realizziamo, non aggiunta a posteriori:

• Architettura di sicurezza — threat modeling, selezione del Secure Element, progettazione della gestione delle chiavi
• Implementazione del Secure Boot — dalla boot ROM fino all’applicazione su piattaforme ARM, RISC-V e FPGA
• Sicurezza del firmware — aggiornamenti OTA firmati, partizionamento A/B, protezione dal rollback
• Progettazione hardware — layout PCB resistenti alla manomissione, protezione della debug port, conformal coating
• Sicurezza FPGA — cifratura del bitstream, motori crypto hardware, integrazione PUF
• Conformità — prontezza al CRA, IEC 62443, marcatura CE
• Test — penetration testing, analisi side-channel, audit di sicurezza

Contattateci per discutere i vostri requisiti di sicurezza IoT, sia per la progettazione di un nuovo prodotto sia per l’hardening di uno esistente.

Fonti e riferimenti ufficiali

• Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Gazzetta ufficiale dell'UE)