Enable secure boot and attestation

Trusted Launch is a built-in platform feature, not a paid add-on. Enabling Secure Boot, vTPM and the guest attestation extension carries no licence charge and no per-machine fee, so the great majority of these findings cost nothing in Azure spend to close. The cost sits entirely in change management: enabling Secure Boot and vTPM on an existing VM requires deallocating and rebooting it, so the work has to be scheduled into a maintenance window rather than billed as a line item.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A VM running a regulated workload or holding sensitive data carries a far higher expected loss from a boot-level compromise than a short-lived build agent, yet both surface as a single low-severity finding. Map the failures to the workloads behind them and prioritise by what a rootkit on that machine would actually reach, not by the recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus a brief reboot for the legitimate machines. The downside of leaving it is a class of compromise, boot-level and below the OS, that your anti-malware and EDR are structurally unable to detect, which is exactly the kind of persistent foothold that turns an incident into a long and expensive one.

Priya is the finance partner supporting the platform team's ISO 27001 push. The security report lands with a cluster of boot-integrity findings spread across dozens of virtual machines in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each finding. Enabling Secure Boot, vTPM and the attestation extension carries no Azure licence charge, so the spend question is narrow: the only real cost is the engineering time to schedule the changes and the brief reboot each VM needs, because enabling Secure Boot and vTPM requires deallocating the machine first.

Priya asks the team to map each unprotected machine to the workload it runs. A handful run the payments API and a customer database, several are internal services, and the rest are short-lived build agents that are recreated from images daily. The list is reframed on the risk register: the payments and database machines are high expected-loss items to schedule into the next maintenance window at zero Azure cost, the build agents are best fixed at the source by switching their image to Trusted Launch so the problem never recurs, and the internal services fall in between. The finance pack reads: 'Every one of these closes at no incremental spend; the only cost is a short reboot per machine, which we batch into the existing maintenance window. The cheapest fix for the disposable fleet is to rebuild it from a Trusted Launch image once, not to touch each machine.'

The cost model here is asymmetric in a way that is rare for security work. Enabling Trusted Launch costs nothing in Azure spend, there is no licence and no per-machine fee, and the only real cost is the maintenance window for a reboot. Against that, leaving it off creates a tail risk that your other tools cannot mitigate: a class of compromise they are structurally unable to detect. While the probability per machine is low, the consequence on a sensitive machine is severe and long-lived, because a boot-level foothold is what turns a contained incident into a months-long one.

The documented cost of a deep, persistent compromise includes prolonged forensics on machines you can no longer fully trust, rebuilds from known-good images, mandatory breach notification and the reputational damage of an intrusion that hid below your defences. Against that, the remediation is engineering time plus a brief reboot per machine, and for disposable fleets it is a one-off image change. The finance role is to attach expected loss to each unprotected machine so the work is prioritised by what a boot-level compromise there would reach, not by the order the report lists it.

Every security tool you pay for runs inside the operating system, and none of them can see a threat that loads before the OS does. A boot-level compromise hides beneath the antivirus, the agent and the firewall, and persists across reboots and reinstalls. The report shows the defence against this as a scatter of low-severity findings across the estate, which understates what they protect.

The leadership question is not 'are we compliant today?' It is 'if something compromised a machine below the operating system, would we ever know?' The defensible end state is that supported machines boot with Secure Boot and vTPM enabled, the platform attests each boot remotely, and Defender raises an alert the moment a machine boots something it should not, an integrity signal no in-guest tool can provide.

None of this is a cost decision. Trusted Launch is a built-in Azure feature with no licence fee. It is a governance decision about whether the estate can prove its machines are trustworthy from the firmware up, or whether it simply assumes they are because nothing has obviously gone wrong yet.

After an industry report described an intrusion that survived a full server rebuild because the attacker had planted a rootkit below the operating system, the CEO asked the obvious question at the next review: if that happened to one of our machines, would we ever find out? The honest answer at the time was probably not, because every detection tool the company ran lived inside the operating system, exactly the layer such a threat boots underneath.

The team's response was to stop treating boot integrity as a per-machine checkbox and start treating it as a platform guarantee. They listed every supported machine running without Secure Boot or vTPM, scheduled the data-bearing ones into maintenance windows to enable both, installed the guest attestation extension so Defender could read each boot remotely, and switched the base images so new machines arrive with Trusted Launch on. Then they set Azure Policy to audit any new machine that lacks it. The next time the CEO asked the question, the answer had changed from 'we probably would not' to 'the platform attests every supported machine's boot, and Defender alerts us the moment one boots something it should not.' That shift, from hoping nothing got in below the OS to having the platform prove it did not, is the confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

The most damaging intrusions are the ones that persist, and persistence at the deepest level means a foothold below the operating system, beneath every tool the company runs to detect it. Trusted Launch is the capability that closes that layer: it stops unsigned boot components from running and lets the platform prove, machine by machine, that the boot was clean. An Azure Policy backstop and a Trusted Launch base image make the safe state the default for everything new.

The cost of getting this wrong is a compromise you cannot see and cannot easily eradicate, while the cost of fixing it is essentially engineering time and a reboot, with no licence fee at all. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.