{"id":1557,"date":"2026-03-19T14:07:23","date_gmt":"2026-03-19T13:07:23","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/secure-boot-certificate-expiration-giugno-2026-migration-strategy-chiavi-uefi-ca-2023-enterprise\/"},"modified":"2026-03-19T14:07:23","modified_gmt":"2026-03-19T13:07:23","slug":"secure-boot-certificate-expiration-giugno-2026-migration-strategy-chiavi-uefi-ca-2023-enterprise","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/secure-boot-certificate-expiration-giugno-2026-migration-strategy-chiavi-uefi-ca-2023-enterprise\/","title":{"rendered":"Come Preparo le Infrastrutture Enterprise alla Secure Boot Certificate Expiration di Giugno 2026: Migration Strategy Completa verso le Chiavi UEFI CA 2023"},"content":{"rendered":"<p>Se amministrate infrastrutture enterprise con centinaia o migliaia di dispositivi Windows, il conto alla rovescia \u00e8 iniziato: i certificati <strong>Microsoft Corporation KEK CA 2011<\/strong> e <strong>Microsoft UEFI CA 2011<\/strong> scadono a <strong>giugno 2026<\/strong>, seguiti dal <em>Microsoft Windows Production PCA 2011<\/em> a ottobre 2026. Non si tratta di un semplice rinnovo: \u00e8 una migrazione completa verso la nuova catena di certificati 2023 che richiede pianificazione, testing e deployment coordinato su physical server, workstation, VM Hyper-V e ambienti VMware.<\/p>\n<p>Nella mia esperienza di system administrator, ho visto troppi colleghi trattare questa scadenza come un &#8220;problema di Windows Update&#8221;. In realt\u00e0, per ambienti enterprise con update gestiti tramite WSUS, SCCM o Intune, <strong>l&#8217;aggiornamento non \u00e8 automatico<\/strong>: richiede intervento manuale tramite registry key, Group Policy o profili Intune. Chi non agisce in tempo rischia dispositivi che non possono pi\u00f9 ricevere aggiornamenti di sicurezza per il boot manager, non si fidano di software di terze parti firmato con le nuove chiavi e restano esposti a vulnerabilit\u00e0 come il bootkit <em>BlackLotus<\/em> (CVE-2023-24932).<\/p>\n<p>In questo articolo vi guido passo dopo passo nella <strong>migration strategy<\/strong> che sto applicando sulle infrastrutture che gestisco: dall&#8217;inventario iniziale al deployment via Intune e Group Policy, fino alla gestione di macchine virtuali e ambienti Linux. Se avete gi\u00e0 letto il mio <a href=\"https:\/\/darioiannascoli.it\/blog\/windows-extended-security-updates-secure-boot-certificate-expiration-2026-aziende\/\">articolo introduttivo sulla scadenza dei certificati Secure Boot<\/a>, qui entriamo nel vivo operativo della migrazione.<\/p>\n<h2>Cosa Scade e Perch\u00e9 Serve una Migration Strategy<\/h2>\n<p>La catena di certificati Secure Boot attuale si basa su tre certificati emessi nel 2011 che Microsoft sta sostituendo con equivalenti 2023:<\/p>\n<ul>\n<li><strong>Microsoft Corporation KEK CA 2011<\/strong> \u2192 <strong>KEK CA 2023<\/strong> (scadenza giugno 2026)<\/li>\n<li><strong>Microsoft Corporation UEFI CA 2011<\/strong> \u2192 <strong>UEFI CA 2023<\/strong> (scadenza giugno 2026)<\/li>\n<li><strong>Microsoft Windows Production PCA 2011<\/strong> \u2192 <strong>Windows UEFI CA 2023<\/strong> (scadenza ottobre 2026)<\/li>\n<\/ul>\n<p>Una novit\u00e0 importante della nuova catena \u00e8 la <strong>separazione tra firma del boot loader e firma delle Option ROM<\/strong>: la UEFI CA 2023 ora distingue questi due ruoli, consentendo un controllo pi\u00f9 granulare sulla trust chain del sistema. Questo \u00e8 particolarmente rilevante per ambienti enterprise con hardware eterogeneo e schede di espansione PCIe con firmware firmato.<\/p>\n<p>I dispositivi prodotti dal 2024 in poi tipicamente includono gi\u00e0 i certificati 2023 nel firmware UEFI. Il problema riguarda il parco macchine esistente \u2014 e nelle aziende, parliamo spesso di dispositivi acquistati tra il 2018 e il 2023 che sono ancora perfettamente funzionanti ma hanno solo i certificati 2011 nel Secure Boot DB.<\/p>\n<h2>Fase 1: Inventario e Assessment del Parco Macchine<\/h2>\n<p>Prima di toccare qualsiasi configurazione, serve un inventario preciso. Ho imparato a mie spese che partire con il deployment senza sapere esattamente cosa c&#8217;\u00e8 in campo porta a brutte sorprese \u2014 soprattutto con firmware UEFI datati che possono reagire male all&#8217;aggiornamento del DB.<\/p>\n<h3>Verificare lo Stato dei Certificati su un Singolo Dispositivo<\/h3>\n<p>Su ogni macchina Windows potete verificare i certificati Secure Boot correnti con PowerShell:<\/p>\n<pre><code># Verifica certificati nel DB Secure Boot\nGet-SecureBootUEFI -Name db | Format-List\n\n# Verifica la KEK\nGet-SecureBootUEFI -Name KEK | Format-List\n\n# Controlla se il certificato 2023 \u00e8 gi\u00e0 presente\n[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match '2023'<\/code><\/pre>\n<p>Se il comando restituisce <code>True<\/code>, il dispositivo ha gi\u00e0 ricevuto l&#8217;aggiornamento. In caso contrario, rientra nel perimetro della migrazione.<\/p>\n<h3>Inventario su Scala con Intune o SCCM<\/h3>\n<p>Per ambienti con Microsoft Intune, potete usare le <em>Device compliance policies<\/em> per identificare i dispositivi che necessitano dell&#8217;aggiornamento. Con SCCM\/MECM, una <em>Configuration Baseline<\/em> con script PowerShell che interroga il DB Secure Boot vi d\u00e0 visibilit\u00e0 completa sul parco macchine.<\/p>\n<p>Il mio consiglio \u00e8 creare tre gruppi:<\/p>\n<ol>\n<li><strong>Gi\u00e0 aggiornati<\/strong> \u2014 certificati 2023 presenti, nessuna azione necessaria<\/li>\n<li><strong>Da aggiornare<\/strong> \u2014 certificati 2011 soli, firmware UEFI compatibile<\/li>\n<li><strong>Problematici<\/strong> \u2014 firmware UEFI datato che potrebbe richiedere aggiornamento preventivo dal vendor<\/li>\n<\/ol>\n<h2>Fase 2: Deployment dei Certificati 2023 via Registry Key<\/h2>\n<p>Il metodo pi\u00f9 diretto per forzare l&#8217;aggiornamento dei certificati Secure Boot su dispositivi enterprise con update gestiti \u00e8 la <strong>registry key <code>AvailableUpdates<\/code><\/strong>. Microsoft ha predisposto un valore specifico che attiva l&#8217;intera catena di aggiornamento.<\/p>\n<h3>Il Valore Magico: 0x5944<\/h3>\n<p>La chiave di registro si trova in:<\/p>\n<pre><code>HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecureBoot<\/code><\/pre>\n<p>Impostando il valore DWORD <code>AvailableUpdates<\/code> a <strong>0x5944<\/strong> (22852 in decimale), Windows procede con:<\/p>\n<ul>\n<li>Installazione dei certificati <strong>KEK CA 2023<\/strong> e <strong>UEFI CA 2023<\/strong> nel database Secure Boot<\/li>\n<li>Aggiornamento del boot manager alla versione firmata con <strong>Windows UEFI CA 2023<\/strong><\/li>\n<li>Aggiornamento della <em>Forbidden Signature Database<\/em> (DBX) per revocare i vecchi boot manager vulnerabili<\/li>\n<\/ul>\n<p><strong>Attenzione<\/strong>: dopo aver impostato il valore, servono <strong>almeno 48 ore e uno o pi\u00f9 riavvii<\/strong> perch\u00e9 l&#8217;aggiornamento si completi. Non \u00e8 un&#8217;operazione istantanea \u2014 il sistema esegue le modifiche al firmware UEFI durante la fase di boot, e alcune operazioni richiedono riavvii multipli.<\/p>\n<h3>Deployment Manuale via Script<\/h3>\n<p>Per un deployment controllato, uso questo script PowerShell che potete distribuire via GPO logon script o task schedulata:<\/p>\n<pre><code># Imposta il registry value per il deployment certificati 2023\n$path = 'HKLM:SYSTEMCurrentControlSetControlSecureBoot'\nif (Test-Path $path) {\n    Set-ItemProperty -Path $path -Name 'AvailableUpdates' -Value 0x5944 -Type DWord\n    Write-Output \"Secure Boot certificate update scheduled on $(hostname)\"\n} else {\n    Write-Warning \"SecureBoot registry path not found on $(hostname)\"\n}<\/code><\/pre>\n<h2>Fase 3: Deployment su Scala con Group Policy e Intune<\/h2>\n<h3>Metodo Group Policy<\/h3>\n<p>Microsoft ha introdotto il setting <strong>&#8220;Enable Secure Boot certificate deployment&#8221;<\/strong> nelle Group Policy amministrative. Per usarlo:<\/p>\n<ol>\n<li>Assicuratevi di avere gli <em>Administrative Templates<\/em> aggiornati (ADMX marzo 2026 o successivi)<\/li>\n<li>Navigate a <code>Computer Configuration \u2192 Administrative Templates \u2192 System \u2192 Secure Boot<\/code><\/li>\n<li>Abilitate il criterio <strong>Enable Secure Boot certificate deployment<\/strong><\/li>\n<li>Linkate la GPO alle OU contenenti i dispositivi target<\/li>\n<\/ol>\n<p>Il vantaggio della GPO \u00e8 la possibilit\u00e0 di fare un rollout graduale: prima su una OU di test, poi progressivamente su tutto il dominio.<\/p>\n<h3>Metodo Microsoft Intune<\/h3>\n<p>Per ambienti cloud-managed con Intune, il deployment \u00e8 altrettanto diretto. Una nota importante: il <strong>servizio di licensing Intune \u00e8 stato aggiornato il 27 gennaio 2026<\/strong> per consentire il deployment delle configurazioni Secure Boot anche su edizioni <em>Pro<\/em> di Windows 10 e 11. Se i dispositivi hanno ricevuto la licenza Intune prima di quella data, potrebbe essere necessario un rinnovo della licenza.<\/p>\n<p>Il profilo Intune si configura tramite <strong>Endpoint Security \u2192 Device configuration<\/strong>, utilizzando un profilo personalizzato con OMA-URI che imposta lo stesso valore di registro 0x5944. In alternativa, potete usare la <strong>Windows Configuration System (WinCS) CLI<\/strong> per deployment scriptati.<\/p>\n<h2>Fase 4: Macchine Virtuali \u2014 Hyper-V e VMware<\/h2>\n<p>Le macchine virtuali meritano un&#8217;attenzione particolare perch\u00e9 il meccanismo di aggiornamento varia significativamente tra gli hypervisor. Nella mia esperienza gestendo ambienti misti, questa \u00e8 la fase che pi\u00f9 facilmente viene dimenticata \u2014 con conseguenze che emergono solo quando \u00e8 troppo tardi.<\/p>\n<h3>Hyper-V<\/h3>\n<p>Le VM Hyper-V si comportano come server fisici: <strong>l&#8217;aggiornamento passa attraverso il sistema operativo guest<\/strong>. Questo significa che potete usare gli stessi metodi descritti sopra (registry key, GPO, Intune) direttamente dentro la VM. Per VM Windows Server, la procedura \u00e8 identica a quella dei server fisici \u2014 come descritto nel <a href=\"https:\/\/darioiannascoli.it\/blog\/aggiornamento-windows-11-marzo-2026-kb5077241-novita-vivetool\/\">mio articolo sull&#8217;aggiornamento di marzo 2026<\/a>, l&#8217;update KB5077241 ha gi\u00e0 iniziato il rollout dei certificati 2023.<\/p>\n<h3>VMware vSphere<\/h3>\n<p>Qui la situazione \u00e8 diversa e pi\u00f9 complessa. Su VMware, l&#8217;aggiornamento dei certificati Secure Boot <strong>avviene lato hypervisor attraverso un aggiornamento del firmware<\/strong>, non dal guest OS. Questo significa che:<\/p>\n<ul>\n<li>Dovete aggiornare i file firmware OVMF\/UEFI sull&#8217;host ESXi<\/li>\n<li>Per VM esistenti potrebbe essere necessario un aggiornamento manuale del Platform Key<\/li>\n<li>Per nuove VM, basta che l&#8217;host abbia il firmware aggiornato \u2014 erediteranno automaticamente i certificati 2023<\/li>\n<\/ul>\n<p>Broadcom ha pubblicato una guida specifica per l&#8217;aggiornamento manuale del Platform Key nelle VM VMware \u2014 se gestite ambienti vSphere, vi consiglio di consultarla e pianificare l&#8217;intervento con anticipo.<\/p>\n<h2>Fase 5: Ambienti Linux e RHEL<\/h2>\n<p>Se nella vostra infrastruttura avete macchine Linux con Secure Boot abilitato (cosa sempre pi\u00f9 comune con RHEL, Ubuntu Server e SUSE in ambienti enterprise), la migrazione dei certificati vi riguarda direttamente. Come ho spiegato nel mio <a href=\"https:\/\/darioiannascoli.it\/blog\/prevenire-ransomware-malware-ai-agents-defensive-security-threat-monitoring-detection-2026\/\">articolo sulla sicurezza con AI agents<\/a>, la supply chain del boot \u00e8 uno dei vettori pi\u00f9 critici.<\/p>\n<p>Per <strong>RHEL<\/strong>, Red Hat ha pubblicato una guida specifica. Il punto chiave \u00e8 aggiornare il pacchetto <code>edk2-ovmf<\/code> sull&#8217;hypervisor o sistema host:<\/p>\n<pre><code># Aggiorna il pacchetto firmware OVMF con i certificati 2023\nsudo dnf update edk2-ovmf\n\n# Verifica che il pacchetto aggiornato includa i certificati 2023\nrpm -q edk2-ovmf<\/code><\/pre>\n<p>Le build pi\u00f9 recenti di <code>edk2-ovmf<\/code> includono sia i certificati 2011 che 2023, garantendo compatibilit\u00e0 con shim firmati con entrambe le chiavi. Questo vi permette di aggiornare immediatamente senza rischi di incompatibilit\u00e0.<\/p>\n<p>Per VM Linux su VMware, ricordate che il workflow automatico di Microsoft <strong>non si applica<\/strong>: dovete usare i meccanismi di aggiornamento Secure Boot supportati da VMware specificamente per guest Linux.<\/p>\n<h2>Timeline e Checklist per IT Manager<\/h2>\n<p>Basandomi sulla mia esperienza con deployment su larga scala, ecco la timeline che consiglio per arrivare preparati a giugno 2026:<\/p>\n<h3>Marzo-Aprile 2026: Preparazione<\/h3>\n<ul>\n<li>Completare l&#8217;inventario del parco macchine<\/li>\n<li>Aggiornare il firmware UEFI sui dispositivi con versioni datate (consultare il vendor)<\/li>\n<li>Verificare la compatibilit\u00e0 degli ADMX template per la GPO<\/li>\n<li>Testare il deployment su un gruppo pilota di 10-20 dispositivi<\/li>\n<li>Aggiornare gli host VMware\/Hyper-V<\/li>\n<\/ul>\n<h3>Aprile-Maggio 2026: Rollout Progressivo<\/h3>\n<ul>\n<li>Deployment via GPO\/Intune sul primo 25% del parco macchine<\/li>\n<li>Monitorare per 48-72 ore, verificare che i riavvii completino l&#8217;aggiornamento<\/li>\n<li>Estendere al 50%, poi al 75%, infine al 100%<\/li>\n<li>Gestire le eccezioni (dispositivi problematici, firmware incompatibili)<\/li>\n<\/ul>\n<h3>Maggio-Giugno 2026: Verifica e Hardening<\/h3>\n<ul>\n<li>Audit finale: tutti i dispositivi devono avere i certificati 2023 nel DB<\/li>\n<li>Verificare le VM Hyper-V e VMware<\/li>\n<li>Aggiornare il pacchetto <code>edk2-ovmf<\/code> sugli host Linux<\/li>\n<li>Documentare le eccezioni e pianificare la sostituzione dei dispositivi non aggiornabili<\/li>\n<\/ul>\n<h2>Errori Comuni da Evitare<\/h2>\n<p>All&#8217;inizio del mio primo deployment pilota, ho commesso un errore che voglio risparmiarvi: ho impostato il registry value e riavviato una sola volta, poi ho verificato \u2014 e i certificati 2023 non c&#8217;erano ancora. Il motivo \u00e8 semplice: <strong>il processo richiede pi\u00f9 riavvii e fino a 48 ore<\/strong>. Non forzate e non panicatevi se dopo il primo reboot non vedete cambiamenti.<\/p>\n<p>Altri errori che ho visto fare:<\/p>\n<ul>\n<li><strong>Dimenticare le VM<\/strong> \u2014 le macchine virtuali sono dispositivi a tutti gli effetti e necessitano dello stesso aggiornamento<\/li>\n<li><strong>Non aggiornare il firmware UEFI prima<\/strong> \u2014 su hardware del 2018-2019 con firmware mai aggiornato, l&#8217;update del DB Secure Boot pu\u00f2 fallire silenziosamente<\/li>\n<li><strong>Ignorare il licensing Intune<\/strong> \u2014 dispositivi con licenza pre-27 gennaio 2026 potrebbero non ricevere il profilo<\/li>\n<li><strong>Non testare il recovery<\/strong> \u2014 in caso di problemi post-update, dovete sapere come accedere al BIOS e gestire il Secure Boot manualmente. Avere un piano di <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-backup-disaster-recovery-business-continuity-ai-predictions-2026\/\">disaster recovery<\/a> \u00e8 fondamentale<\/li>\n<\/ul>\n<h2>Connessione con la Sicurezza dell&#8217;Infrastruttura<\/h2>\n<p>Questa migrazione non \u00e8 solo un adempimento tecnico: \u00e8 una misura di sicurezza critica. I certificati 2023 sono stati introdotti anche per mitigare definitivamente la vulnerabilit\u00e0 <strong>BlackLotus<\/strong> (CVE-2023-24932), un bootkit UEFI che ha dimostrato come un attaccante potesse bypassare Secure Boot su sistemi con i vecchi certificati 2011.<\/p>\n<p>Se gestite infrastrutture enterprise, questa migrazione si inserisce nel quadro pi\u00f9 ampio della compliance \u2014 penso alla <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-conforme-direttiva-nis2-logging-action-log-autenticazione-checklist\/\">direttiva NIS2<\/a> e al <a href=\"https:\/\/darioiannascoli.it\/blog\/vulnerability-disclosure-program-wordpress-plugin-cyber-resilience-act-2026\/\">Cyber Resilience Act<\/a> che richiedono alle organizzazioni di mantenere aggiornata la catena di trust dei propri sistemi.<\/p>\n<p>Inoltre, se state pianificando la vostra <a href=\"https:\/\/darioiannascoli.it\/blog\/cloud-3-edge-computing-hybrid-multi-cloud-latenza-agenti-ai-sovereign-cloud-italiano-2026\/\">strategia hybrid multi-cloud<\/a>, considerate che anche le istanze cloud con Secure Boot abilitato (come le <em>Shielded VMs<\/em> su Azure) necessitano dello stesso aggiornamento. Microsoft ha annunciato una soluzione specifica per Azure nella release 2603 di marzo 2026.<\/p>\n<h2>FAQ<\/h2>\n<h3>Cosa succede se non aggiorno i certificati Secure Boot prima di giugno 2026?<\/h3>\n<p>I dispositivi non aggiornati non potranno pi\u00f9 ricevere aggiornamenti di sicurezza per il boot manager Windows, non si fideranno di software firmato con le nuove chiavi 2023 e resteranno vulnerabili a exploit come BlackLotus. Il boot di Windows continuer\u00e0 a funzionare fino a ottobre 2026, quando scade anche il Production PCA 2011, ma senza protezione aggiornata.<\/p>\n<h3>Il deployment del registry value 0x5944 pu\u00f2 causare problemi di boot?<\/h3>\n<p>Su hardware con firmware UEFI aggiornato, il rischio \u00e8 minimo. Tuttavia, su dispositivi con firmware molto datato (pre-2020 mai aggiornato), possono verificarsi problemi. Per questo consiglio sempre di aggiornare il firmware UEFI dal vendor prima di procedere, e di testare su un gruppo pilota. In caso di problemi, \u00e8 possibile accedere al setup UEFI e ripristinare le impostazioni Secure Boot ai valori di fabbrica.<\/p>\n<h3>Le macchine Linux con Secure Boot sono interessate dalla scadenza?<\/h3>\n<p>S\u00ec. Le distribuzioni Linux enterprise come RHEL, Ubuntu e SUSE usano shim firmati da Microsoft per il boot con Secure Boot abilitato. Aggiornando il pacchetto <code>edk2-ovmf<\/code> sugli host e il bootloader shim sulle VM, si garantisce la compatibilit\u00e0 con i nuovi certificati 2023. Red Hat ha pubblicato una guida dettagliata per ambienti RHEL.<\/p>\n<h3>Posso distribuire l&#8217;aggiornamento tramite WSUS?<\/h3>\n<p>L&#8217;aggiornamento dei certificati Secure Boot viene distribuito anche tramite Windows Update e WSUS, ma per dispositivi con update gestiti centralmente (dove gli aggiornamenti automatici sono limitati), il metodo pi\u00f9 affidabile resta l&#8217;impostazione manuale del registry value 0x5944 o il deployment via Group Policy\/Intune. WSUS distribuisce l&#8217;update come aggiornamento opzionale che richiede approvazione esplicita.<\/p>\n<h3>Quanto tempo richiede il deployment completo su un parco di 500+ dispositivi?<\/h3>\n<p>Nella mia esperienza, pianificate almeno 4-6 settimane per un deployment completo: 1 settimana per l&#8217;inventario e il pilota, 2-3 settimane per il rollout progressivo (considerando i 48 ore + riavvii per dispositivo) e 1-2 settimane per gestire eccezioni e verifiche finali. Non cercate di fare tutto in una settimana \u2014 il processo fisico di aggiornamento del firmware UEFI ha i suoi tempi.<\/p>\n<h2>Conclusione<\/h2>\n<p>La <strong>scadenza dei certificati Secure Boot a giugno 2026<\/strong> \u00e8 una di quelle deadline che non si possono rimandare. A differenza di molti aggiornamenti software, questa migrazione tocca il firmware UEFI \u2014 il livello pi\u00f9 basso e critico della catena di boot \u2014 e richiede tempo, pianificazione e testing.<\/p>\n<p>Il mio consiglio \u00e8 iniziare subito con l&#8217;inventario e il gruppo pilota. Con la registry key 0x5944, Group Policy e Intune avete tutti gli strumenti per gestire il deployment su scala enterprise. Non dimenticate le VM (sia Hyper-V che VMware) e gli ambienti Linux, che richiedono procedure specifiche.<\/p>\n<p>Se avete dubbi sulla procedura o volete condividere la vostra esperienza con la migrazione dei certificati Secure Boot 2023 nella vostra azienda, lasciate un commento \u2014 \u00e8 sempre utile confrontarsi con chi sta affrontando la stessa sfida.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida completa alla migrazione dei certificati Secure Boot verso le chiavi UEFI CA 2023 prima della scadenza di giugno 2026: deployment via registry, GPO, Intune e gestione VM.<\/p>\n","protected":false},"author":1,"featured_media":1558,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Secure Boot Certificate Expiration 2026: Migration Strategy Enterprise","_seopress_titles_desc":"Come preparare l'infrastruttura enterprise alla scadenza certificati Secure Boot giugno 2026: deployment chiavi UEFI CA 2023 via GPO, Intune e registry.","_seopress_robots_index":"","footnotes":""},"categories":[6],"tags":[472,471,473,361,470,469],"class_list":["post-1557","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows","tag-certificati-digitali","tag-enterprise-security","tag-intune","tag-secure-boot","tag-uefi","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1557","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1557"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1557\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1558"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1557"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1557"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1557"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}