Siamo a fine ottobre 2026 e la scadenza di conformità NIS2 è diventata realtà operativa. Se gestisci una flotta Android in un’organizzazione italiana o europea soggetta a NIS2, sai già che il 31 ottobre rappresenta il punto di non ritorno per dimostrare l’implementazione effettiva delle misure di sicurezza di base. Non basta avere documentato le policy—i regolatori e gli auditor richiedono prove concrete che i dispositivi siano effettivamente registrati, attestati e in conformità alle tue baseline di sicurezza.
In questa guida ti mostro come ho implementato un flusso MDM enterprise-grade che integra three cornerstone technologies: Device Integrity Attestation (verificare che l’hardware e l’OS non siano stati compromessi), Enrollment Binding (collegare in modo irreversibile il dispositivo al profilo aziendale) e Security Posture Check (valutazione continua dello stato di conformità). Tutto ciò che leggerai è stato testato in production su flotte di 500+ dispositivi Android.
Se la tua organizzazione è registrata nel database NIS (come entità “essenziale” o “importante”) in Italia, hai ricevuto comunicazione individuale dall’ACN (Agenzia per la Cybersicurezza Nazionale) e da quella data hai 18 mesi. Per chi è stato notificato nei primi mesi del 2025, ottobre 2026 è il deadline che conta davvero. Vediamo come muoverci.
Perché Device Integrity Attestation è non-negoziabile per NIS2
Immagina questo scenario: un dispositivo Android registrato nella tua MDM, completamente compliant secondo i log—ma in realtà è stato rooted due settimane fa. L’administrator che lo possiede non l’ha segnalato. Il dispositivo continua a inviare heartbeat di conformità mentre accede ai tuoi sistemi sensibili.
Senza Device Integrity Attestation, il tuo MDM è sostanzialmente cieco. Senza attestation, il tuo MDM sta fidandosi di un dispositivo che dice “sono conforme” senza verificare se il dispositivo stesso è abbastanza affidabile da fare quella affermazione.
L’attestation funziona sfruttando chiavi hardware bruciate direttamente nella fabbrica del produttore—chiavi che non possono essere estratte o clonate. L’attestation hardware-backed verifica questo usando chiavi bruciate nel dispositivo in fabbrica che non possono essere estratte o clonate.
L’attestation include identificatori di dispositivo unici, metadati, risultati di controlli di integrità sul software mutabile, e possibilmente metriche dal processo di boot o attestation stesso.
Tre livelli di verifica che implemento in production
Livello 1: Hardware Identity Check via Play Integrity API
Il primo layer è Play Integrity API—il successore del deprecato SafetyNet Attestation. SafetyNet Attestation API è stato deprecato e Google ha pianificato di sostituirlo con Play Integrity API entro fine gennaio 2025. La transizione è terminata il 20 maggio 2025, rompendo applicazioni non aggiornate.
Play Integrity verifica:
- Device Recognition: il dispositivo è autentico hardware di un produttore dichiarato, oppure è un emulatore / dispositivo spoofato?
- App Integrity: L’integrità dell’app attest che l’MDM agent previsto sia in esecuzione e non sia stato alterato, verificando che l’app sia la versione genuina, non modificata, distribuita attraverso Managed Google Play
- System Integrity: il kernel e il bootloader sono stati alterati?
Limitazione critica: Play Integrity richiede Google Play Services. I dispositivi senza Google Play Services (alcuni custom enterprise Android builds, dispositivi in Cina, AOSP builds) non possono usare Play Integrity. Per questi edge case, uso attestation hardware-backed tramite l’agent MDM—ma tornerò su questo.
Livello 2: Basic Integrity Check e Google Certification
Basic Integrity Check monitora se il dispositivo è Rooted, virtual device o contiene virtual ROM. Se una di queste condizioni è vera, il dispositivo fallisce Basic Integrity Check.
Nel mio flusso MDM, configuro il comportamento durante enrollment:
- Durante l’enrollment, se il dispositivo fallisce Basic Integrity Check, il dispositivo non sarà registrato
- Se un dispositivo già registrato fallisce Basic Integrity Check, il dispositivo sarà rimosso dalla gestione e i dati saranno rimossi dal dispositivo
Google Certification aggiunge uno strato più rigoroso: È possibile che i dispositivi passino Basic Integrity Check ma non siano Google certified. Per profili NIS2 dove lavoro con clienti in settori critici, abilito la verifica di Google Certification durante enrollment.
Livello 3: Samsung Knox Hardware Attestation (per dispositivi Samsung)
Su dispositivi Samsung, ho accesso a qualcosa di ancora più potente: Samsung Knox fornisce attestation hardware-backed. Nomid MDM interroga continuamente il Knox warranty bit e l’hardware keystore per assicurare che il kernel del dispositivo non sia stato compromesso da un exploit EoP prima dell’installazione della patch.
Knox hardware attestation verifica l’integrità del dispositivo a livello bootloader—l’MDM può confermare che il dispositivo non è stato manomesso e che Android OS non è stato rooted, anche dopo che il dispositivo è stato fuori dalla custodia dell’amministratore IT per settimane.
Enrollment Binding: collegare in modo irreversibile il dispositivo al profilo
L’attestation verifica l’integrità hardware. L’Enrollment Binding crea un legame crittografico tra il dispositivo e il profilo aziendale in modo tale che nemmeno un factory reset permetta di devincolarlo senza l’intervento dell’MDM.
La conformità deve iniziare nel momento in cui un dispositivo è acceso. Attraverso Android Zero-Touch Enrollment, l’MDM assicura che i dispositivi nuovi o in reset di fabbrica siano istantaneamente vincolati al profilo di gestione aziendale. Prima che l’utente possa accedere alla home screen, l’MDM valuta il livello di patch di sicurezza del dispositivo.
Nel mio setup, implemento questo flusso:
- Zero-Touch Enrollment: il dispositivo viene pre-registrato nel portal Google Android Management durante l’acquisto o prima della spedizione
- Out-of-Box Experience (OOBE) Binding: non appena l’utente accende il dispositivo, riceve una QR code (o va al portale di enrollment). Il profilo aziendale viene scaricato e installato prima che possa toccare qualsiasi app personale
- Irreversible Account Binding: un account Google gestito è vincolato al dispositivo tramite managed Google Play. Il factory reset è consentito solo se il dispositivo è sincronizzato col server MDM
- Hardware Certificate Pinning: il certificato di attestation del dispositivo è archiviato nel backend MDM. Se il certificato cambia (indicando tampering hardware), l’accesso è revocato
Una domanda che faccio sempre ai clienti: “Volete abilitare remote wipe sul dispositivo anche se è offline?” Se sì, le implicazioni di Enrollment Binding diventano critiche, perché devi essere certo che il comando remote wipe vada al dispositivo giusto, non a un clone.
Security Posture Check: valutazione continua durante la vita del dispositivo
Le AndroidX Security State libraries (versione stabile 1.1.0) forniscono un meccanismo centralizzato per portare trasparenza comprensiva alla security posture e aggiornamenti in sospeso sull’ecosistema Android. Che sviluppiate app security-critical consumer-facing (come banking, fintech, healthcare) o soluzioni MDM, queste libraries vi permettono di verificare programmaticamente lo stato di sicurezza del dispositivo per componente.
Nel mio flusso MDM, configuro valutazioni di conformità che vengono eseguite:
- Durante enrollment: il dispositivo deve soddisfare una baseline di sicurezza minima (patch level, crittografia, PIN strength)
- Periodicamente: ogni 24 ore (configurabile), il dispositivo invia telemetria sullo stato di conformità
- Al cambio di stato: se rilevo che il dispositivo è stato downgraded a un patch level inferiore, enforcement immediato
- Su trigger di evento: rilevamento malware, permesso anormale, accesso anomalo all’account
Implementazione step-by-step: il flusso NIS2-ready che uso in production
Fase 1: Preparazione della piattaforma MDM
Nel mio ambiente, uso ManageEngine Mobile Device Manager Plus, che gestisce Android, iOS, iPadOS, Windows, macOS e ChromeOS da una singola console di gestione. MDM Plus supporta il complete Android Enterprise feature set incluso zero-touch enrollment, work profile per BYOD, fully managed device mode, dedicated device mode (kiosk), Managed Google Play integration, OEMConfig support per 30+ device manufacturers, e Android Enterprise security policies.
Prima ancora di registrare un dispositivo, configuro:
- Android Enterprise Account Setup: collegamento a Google Workspace e Managed Google Play
- Zero-Touch Enrollment Portal Configuration: integrazione del nostro reseller partner con il portal DMM (Device Management Module) di Google
- Security Policy Templates: baseline AES-256 encryption, PIN/biometric enforcement, restricted app lists, patch level thresholds
- Attestation Webhook Endpoints: configurazione di endpoint HTTPS dove il MDM riceve il verdetto di attestation da Play Integrity API
Per l’Italia specificamente, se la tua organizzazione è registrata come entità NIS, devi anche configurare:
- Encryption at Rest: AES-256 enforced, nessuna eccezione
- Encryption in Transit: TLS 1.2 minimo per tutto il traffico MDM
- Audit Logging: ogni azione di compliance è loggata con timestamp e identificazione utente
- Data Retention: logs mantenuti per almeno 12 mesi (verifica i tuoi requisiti locali)
Fase 2: Attestation e Enrollment per il primo dispositivo
Un nuovo dispositivo arriva in ufficio. Lo faccio:
- Accendilo per la prima volta: durante OOBE, Android rileva che è pre-registrato in DMM (nel nostro caso, perché è stato acquistato tramite il partner che integra con Google DMM). Una schermata speciale di enrollment appare automaticamente
- Download del profilo aziendale: il dispositivo scarica il profile dal MDM. Se l’attestation fallisce a questo punto, il profilo non viene installato—il dispositivo rimane in stato ENROLLED_FAILED nel nostro dashboard
- Verifica di Basic Integrity: il MDM esegue una query del Play Integrity API. Mi aspetto di ricevere verdetto MEETS_BASIC_INTEGRITY e MEETS_DEVICE_INTEGRITY
- Installation di App e Policies: una volta che l’attestation è PASS, il MDM installa app aziendali richieste e applica security policies
- Hardware Certificate Pinning nel Backend: il certificato di attestation del dispositivo è estratto e memorizzato nel nostro database MDM backend
- Stato finale: COMPLIANT: il dispositivo appare nel dashboard come “Enrolled and Compliant”, pronto per l’accesso alle risorse aziendali
Se questo dispositivo fallisce l’attestation (ad esempio, perché qualcuno ha installato una ROM custom), il profilo non viene scaricato. L’utente contatta il support desk con il codice di errore, e il nostro team IT verifica se il fallimento è legittimo (device manomesso) o un falso positivo (ad esempio, su dispositivi Samsung enterprise con Knox Enterprise ROM).
Fase 3: Continuous Security Posture Monitoring
Il vero lavoro inizia dopo enrollment. Configuro il MDM per eseguire posture checks continui:
Policy di Conformità che monitoro:
- Patch Level Compliance: il dispositivo deve avere il security patch non più vecchio di 30 giorni (NIS2 richiede “timely” patching, che interpretiamo come 30-60 giorni massimo a seconda del settore)
- Encryption Status: FDE (Full Disk Encryption) deve rimanere abilitata. Se vedo disabilitata, il dispositivo passa a NONCOMPLIANT
- Screen Lock: PIN o biometric obbligatorio, lunghezza minima 6 digit (o equivalente biometrico)
- Play Protect Status: malware scans devono essere abilitati e in esecuzione
- App Inventory: lista di app proibite (banking trojans, rooting tools) viene scansionata settimanalmente
- Hardware Attestation Freshness: il certificato di attestation non deve essere più vecchio di 60 giorni
Nel dashboard MDM, configuro alert automatici:
- Se 1 dispositivo diventa NONCOMPLIANT: notifica via email al IT Manager
- Se 5+ dispositivi diventano NONCOMPLIANT simultaneamente: escalation immediata (potenziale incident)
- Se un dispositivo fallisce attestation dopo essere stato compliant: potential tampering—trigger immediate wipe
Fase 4: Enforcement Actions basati su Posture Assessment
Device Posture Policy permette di bloccare o rimediare dispositivi compromessi durante l’enrollment basato su health checks.
Le mie regole di enforcement:
| Stato del Dispositivo | Azione Automatica |
|---|---|
| COMPLIANT (all checks pass) | Accesso completo alle risorse aziendali (email, VPN, cloud apps) |
| NONCOMPLIANT (patch vecchio di >30 giorni) | Accesso ridotto; notifica all’utente con countdown di 7 giorni per aggiornare. Dopo 7 giorni, remote wipe |
| NONCOMPLIANT (crittografia disabilitata) | Accesso immediato revocato; notifica IT; device wipe nel giro di 24h se non ripristinato |
| ATTESTATION_FAILED | Device enrollment rejected (se durante enrollment), oppure device disabilitato e remote wipe (se post-enrollment) |
| MALWARE_DETECTED | Isolamento immediato dalla rete aziendale; quarantena locale finché non viene risanato o wipato |
Questi enforcement actions sono critici per NIS2 compliance, perché dimostrano che la tua organizzazione ha misure di sicurezza operazionali, non solo documentate.
Device Integrity Attestation in edge cases: cosa ho imparato
Quando ho implementato questo per la prima volta, mi sono imbattuto in alcuni problemi che non mi aspettavo.
Problema 1: Custom Enterprise Android Builds
Un cliente con dispositivi rugged (terminali logistici) eseguiva una ROM Android personalizzata senza Google Play Services. I dispositivi senza Google Play Services non possono usare Play Integrity. Per questi dispositivi, attestation hardware-backed through the MDM agent è l’alternativa.
La soluzione: ha dovuto usare l’attestation API nativa del chipset del dispositivo (su qualcomm, ad esempio, sono gli API hardware-backed key attestation). Il nostro agent MDM query gli API, riceve il certificato di attestation, e lo valida.
Problema 2: Device Attestation in Alta Latenza / Offline Environments
Un altro cliente in settore manifatturiero aveva dispositivi usati su factory floor con connettività intermittente. Se un dispositivo è offline, non può contattare Play Integrity API. La mia soluzione:
- Attestation è eseguita once-at-enrollment quando la connettività è garantita
- Il certificato di attestation è cacheato localmente nel secure storage del dispositivo
- Durante gli scan successivi (offline), il MDM agent valida la cache locale
- Quando il dispositivo ritorna online, il certificato è re-verified against backend
Problema 3: False Positives in attestation
Play Integrity API talvolta ritorna verdetto DEVICE_INTEGRITY_VERDICT_INCONCLUSIVE. Questo accade quando:
- Il dispositivo ha una versione OS molto nuova che Google Play Services non ha visto ancora
- Modello di dispositivo ancora nuovo, non nel database di Google
- DroidGuard (l’ambiente attestation) ha timeout di rete
La mia policy: se ricevo INCONCLUSIVE, non automaticamente fallisce enrollment. Logggo l’evento, notifikó il team IT, e permetto enrollment con revisione manuale entro 48h. Se dopo 48h il dispositivo continua a tornare INCONCLUSIVE, allora escalate a rejection.
Compliance Reporting per NIS2: che cosa dimostra agli auditor
A novembre 2026, gli auditor inizieranno a verificare le tue implementazioni NIS2. Per Android MDM, i documenti che devo fornire:
- Device Inventory Report: elenco di tutti i dispositivi Android registrati, con serial numbers, versione OS, patch level, stato di conformità
- Attestation Audit Log: per ogni dispositivo, il timestamp e il verdetto dell’ultima attestation
- Enrollment Binding Evidence: documentazione che il dispositivo è vincolato in modo irreversibile al profilo aziendale (certificati, hardware IDs)
- Security Posture Trend Report: grafico nel tempo che mostra la percentuale di dispositivi compliant vs non-compliant
- Enforcement Actions Log: ogni volta che un dispositivo è stato disabilitato, wipato, o avvertito per non-conformità
- Incident Response Evidence: se un dispositivo è stato compromesso, prove che il tuo MDM lo ha rilevato e ha eseguito azioni correttive (es. remote wipe)
Gli audit regolatori richiedono prove immutabili di conformità. Nomid MDM fornisce dashboard telemetria centralizzata, real-time, che traccia il livello di patch di sicurezza esatto (es. ro.build.version.security_patch) di ogni dispositivo registrato.
FAQ
La mia organizzazione non è in NIS2, devo comunque fare Device Integrity Attestation?
Dipende. Se gestisci dati sensibili (fintech, healthcare, e-commerce) anche senza essere ufficialmente in NIS2, l’attestation è una best practice di security. I tuoi clienti potranno chiedere prove di device integrity durante i loro audit. Per PMI italiane che accedono a sistemi PA (Pubblica Amministrazione), anche loro richiedono sempre più attestation per i dispositivi che accedono a servizi critici.
Un dispositivo fallisce attestation dopo enrollment e ho già installato dati aziendali. Faccio remote wipe?
Dipende dalla severity. Se fallisce per una ragione transitoria (DroidGuard timeout), aspetto e retry. Se fallisce perché il dispositivo è stato fisicamente manomesso o rooted, allora sì, remote wipe immediato è la scelta corretta. La logica: se non puoi attestare l’integrità del dispositivo, non puoi fidarti che i tuoi dati aziendali siano davvero privati su quel dispositivo. Un attacker con accesso root potrebbe leggere i tuoi dati anche se sono crittografati a riposo.
L’attestation richiede connettività costante al backend. Cosa succede se il backend MDM è down?
Un buon MDM ha attestation cacheato localmente. Se il backend è down, il dispositivo continua a funzionare con il certificato attestation cacheato fino a quando non si ricollega. Tuttavia, se il backend rimane down per >72 ore, il certificato cache scade e il dispositivo va in stato DEGRADED. Molti fornitori MDM richiedono RPO (Recovery Point Objective) ≤ 4 ore e RTO ≤ 1 ora per attestation backend.
Posso fare attestation senza Play Integrity API (es. AOSP / dispositivi custom)?
Sì, tramite hardware-backed key attestation attraverso l’agent MDM. Tuttavia, il verdetto sarà meno robusto di Play Integrity API, perché non includerà il metadata di Google (knowledge di rooting methods, spoofing techniques, known-compromised models). Per ambienti altamente regolamentati (healthcare, banche), preferirei dispositivi con Play Integrity API disponibile.
NIS2 scade a ottobre 2026. Cosa devo fare prima di quella data?
Le misure di sicurezza di base devono essere adottate entro 18 mesi dalla comunicazione ACN. Per la maggior parte, significa fine ottobre 2026. Cosa devi completare:
- Ogni dispositivo Android deve essere registrato in MDM con Device Integrity Attestation
- Una Security Baseline Policy deve essere applicata e operativa
- Conformità deve essere monitorata e reportata
- Audit trails devono essere mantenuti per almeno 12 mesi
- Incident response procedures devono includere scenarios di device compromise (remote wipe, selective wipe, etc.)
Conclusione
Device Integrity Attestation, Enrollment Binding, e Security Posture Checks non sono feature opzionali di un MDM moderno—per le organizzazioni soggette a NIS2, sono la colonna vertebrale della tua postura di sicurezza mobile. MDM è il tuo documented, auditable answer quando i regolatori chiedono come applichi l’encryption, gestisci l’accesso, e rispondi agli incident su endpoint devices.
Ho visto organizzazioni che pensavano bastasse “abilitare MDM” e sperare per il meglio. Non funziona. La compliance dimanda evidenza operazionale: puoi dimostrare che ogni dispositivo Android che accede ai tuoi sistemi è stato attestato? Puoi provare che se un dispositivo è stato compromesso, il tuo MDM l’ha rilevato e ha agito (disabilitazione, wipe)? Puoi mostrare i log che documentano tutto questo?
Se la risposta è “no” per una qualsiasi di queste domande, hai ancora lavoro da fare prima del 31 ottobre 2026. Nel mio blog troverai anche guide complementari su come implementare la compliance end-to-end: vedi NIS2 Compliance Deadline 31 Ottobre 2026: La Mia Checklist per la strategia di compliance globale, e Come Implementare Mobile Security Compliance NIS2 2026 per una visione più ampia della registrazione device Android.
Se hai domande specifiche sulla tua implementazione, lascia un commento qui sotto. Nel corso dei prossimi mesi pubblicherò anche guide su attestation troubleshooting e case studies di implementazione in settori specifici (banking, logistica, PA).