Protection must start before the regular antivirus service

A domain controller restarts after a maintenance window, the EDR agent checks in and services are running. This does not yet demonstrate that kernel drivers loaded early in startup were assessed reliably. Storage, encryption, backup and security products include components that initialize before antivirus protection reaches normal operation. An inherited legacy installation or a poorly controlled agent migration can leave a gap at this point.

Early Launch Anti-Malware, or ELAM, gives a specially signed antimalware driver an early inspection point during Windows startup. It assesses subsequent boot-start drivers and their dependent DLLs. The kernel uses this classification and the boot policy to decide which components may initialize. For Microsoft Defender Antivirus, Wdboot.sys performs this task.

For AD hardening, this is particularly relevant to domain controllers, identity servers and privileged admin workstations: their trustworthiness also depends on operating system startup. ELAM does not change AD permissions or solve password problems. It strengthens an underlying protection layer.

Target state: verified startup with predictable recovery

A workable target state has five elements:

  • The ELAM provider is known and functional. The installed security product, its boot component and its update path are documented.
  • The boot policy is chosen deliberately for each device class. Standard clients, storage servers, virtual DCs and physical admin devices do not receive an untested blanket change.
  • The chain of trust is considered as a whole. Supported Windows versions, current firmware, Secure Boot and protected endpoint management form the foundation.
  • Every change ends with a verified restart and functional test. An applied GPO alone is not acceptance evidence.
  • Recovery works without a normal Windows sign-in. The console, recovery environment, BitLocker keys and approved replacement versions are accessible.

Secure Boot protects the handoff from UEFI firmware to a trusted bootloader. Trusted Boot continues integrity checks for Windows startup components. ELAM adds antimalware assessment of boot-start drivers to this chain. The Vulnerable Driver Blocklist and HVCI cover other aspects of driver execution; they do not replace this checkpoint, just as ELAM does not replace ongoing AV/EDR protection.

What each boot policy costs

The English GPO is called Boot-Start Driver Initialization Policy. Its path is Computer Configuration > Policies > Administrative Templates > System > Early Launch Antimalware. In German administrative templates, the path is Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Antischadsoftware-Frühstart > Richtlinie für Bootstarttreiber-Initialisierung.

The options describe permitted ELAM classes, not a list of approved vendors:

  • Good, unknown and bad but critical — value 3: Windows also permits drivers classified as malicious if they are critical to boot. Other drivers classified as malicious do not initialize. This is the default and provides an initial baseline that can be documented.
  • Good and unknown — value 1: Drivers classified as malicious are excluded even if they are critical to boot. This is a stricter decision, but it can prevent the system from starting.
  • Good only — value 8: Unknown components are also excluded. A legitimate driver that the provider has not classified can therefore cause an outage. This option requires a tightly controlled and fully tested platform.
  • All — value 7: ELAM classification does not block any drivers. This is not a suitable permanent hardening target.

Disabled and Not configured use the default selection; they do not disable ELAM itself. Conversely, enabling the GPO without a functional ELAM driver does not deliver the corresponding protection. Moving from the unchanged default to an explicit selection of 3 improves traceability but does not make the blocking decision stricter.

“Bad but critical” is not a harmless compatibility warning. It remains a malware finding. If the boot policy prioritizes availability and allows startup, the finding still requires incident handling. A reachable DC is therefore not necessarily a trustworthy DC.

1. Record the provider, drivers and existing state

For each pilot group, record at least the Windows build, hardware or VM platform, firmware, security product, platform version, boot-start drivers, Secure Boot state and responsible operations team. ELAM was introduced with Windows 8 and Windows Server 2012; that does not imply these old operating systems are supported today.

For Microsoft Defender, platform updates maintain the ELAM driver. Current security intelligence alone therefore does not establish that the platform is up to date. For third-party products, the vendor must confirm ELAM support for the product version in use. An EDR license or a running sensor is not sufficient evidence.

The following query reads the explicit administrative boot policy from an elevated PowerShell session. It does not change any settings:

Set-StrictMode -Version Latest

$policyPath = 'HKLM:\SYSTEM\CurrentControlSet\Policies\EarlyLaunch'
$policyValue = $null

try {
  if (Test-Path -LiteralPath $policyPath -ErrorAction Stop) {
    $policyKey = Get-Item -LiteralPath $policyPath -ErrorAction Stop
    $policyValue = $policyKey.GetValue('DriverLoadPolicy', $null)
  }

  [pscustomobject]@{
    ComputerName = [Environment]::MachineName
    ExplicitDriverLoadPolicy = if ($null -eq $policyValue) {
      'Not configured'
    } else {
      $policyValue
    }
  }

} catch {
  throw 'ELAM policy query failed. Check elevation and local registry access.'
}

Then run the boot-driver inventory as a separate query so that PowerShell displays the different object columns separately:

Get-CimInstance -ClassName Win32_SystemDriver `
  -Filter "StartMode = 'Boot'" -ErrorAction Stop |
  Select-Object Name, DisplayName, State, PathName |
  Sort-Object Name

The administrative value is stored under Policies\EarlyLaunch. Do not confuse the separate Control\EarlyLaunch location with this GPO evidence. Internal driver values in developer documentation are also not a reliable reference for the administrative selection; for this GPO, Good only corresponds to value 8.

The inventory does not show ELAM classifications. An absent policy value only means that no explicit selection was established at this location. Read failures remain errors and must not be reported as either the default configuration or confirmed protection in a compliance report.

2. Create a dedicated pilot GPO with clear stop criteria

Back up the existing configuration and use a separate computer GPO with a small, verifiable scope. Check linking, security filtering and potentially competing MDM management. The GPO must actually take precedence for the intended setting on the target system.

Document the existing rule first. Then assess whether Good and unknown is viable for the platform: this prevents a driver classified as malicious from initializing even if it is critical to boot. The availability consequences must be accepted and technically manageable before the change. Good only is a further restriction and requires a separate testing decision.

The ELAM GPO has no dedicated audit mode comparable to App Control. A permissive boot policy is not an audit mode for a stricter policy. The pilot must therefore test the actual planned selection before it reaches production device groups.

Suitable stop criteria include failed startup, unexpected BitLocker recovery, a failed storage or network path, missing endpoint protection or inaccessible management. Security findings are investigated in parallel; reverting the stricter policy does not make them disappear.

3. Test restarts against actual operating scenarios

The boot policy takes effect at the next system startup. A successful gpupdate does not reinitialize drivers that are already running. Schedule a real restart within the change window and also test cold starts where relevant to the platform. On clients, Fast Startup can mean that a normal shutdown followed by power-on is not equivalent to a full startup.

The test scope should include at least:

  • Restart, sign-in and reachability through the intended administration path;
  • Storage, encryption, networking, backup and AV/EDR functionality;
  • A routine platform, driver and Windows update followed by a restart;
  • Recovery through the intended console and recovery environment;
  • For virtual systems, the virtual hardware and security configuration actually used.

Domain controllers follow only after representative tests, and one at a time. Before each restart, the remaining DCs must be able to handle authentication and DNS. Afterwards, acceptance checks must cover AD replication, DNS, SYSVOL/NETLOGON and operational monitoring. A VM snapshot does not replace a supported AD recovery procedure.

4. Verify configuration and actual startup separately

gpresult /scope computer /r shows applied computer GPOs. For the specific boot policy, also use the Group Policy Results report or RSoP and the policy value read from the registry. Confirm-SecureBootUEFI checks Secure Boot state on supported UEFI systems; it requires elevated privileges. An error or an unavailable cmdlet is not positive evidence.

The ELAM driver unloads after its early startup phase. A stopped WdBoot driver after sign-in therefore does not prove a failure. An existing BackupPath under Control\EarlyLaunch is likewise only a configuration indicator. None of these individual signals replaces verification of the actual startup process.

Agree on evidence appropriate to the product version with the endpoint operations team: the expected boot component, a current platform, successful restarts, vendor diagnostics and associated detection telemetry. For Defender, ELAM detections appear through Defender's detection reporting, for example as event 1006; this event is not a general “ELAM started successfully” signal.

Bring together policy state, platform version, restart time and verification results. Missing messages can also indicate a failed sensor or a broken collection path. Acceptance requires positive operational evidence and a tested route for security alerts.

5. Rehearse recovery before the wider rollout

A system that cannot start will not receive a corrective GPO. Accessible out-of-band or VM consoles, WinRE, approved replacement packages and a documented rollback of the pilot configuration must therefore be in place before the first production restriction. Where BitLocker is used, the corresponding recovery keys must remain available through controlled access even if AD access is disrupted; keys belong neither in tickets nor in diagnostic output.

Distinguish a legitimate driver blocked as unknown from an actual malware finding. In the first case, priorities are vendor clarification, a compatible update or rollback of the pilot policy. The second case also requires isolation, evidence preservation and, where necessary, a clean rebuild. Simply unblocking the driver does not remediate a compromise.

Windows provides temporary disabling of early launch antimalware protection in Startup Settings for recovery. This option belongs exclusively in an approved, bounded recovery procedure, followed by remediation of the cause and renewed protection checks. It is not a permanent baseline. Blanket disabling of Secure Boot or other protection layers is not sound troubleshooting either.

Benefits for AD operations

  • An early checkpoint: Drivers classified as malicious can be stopped before initialization, before regular protection services take over.
  • A deliberate risk decision: The organization decides whether a malware finding on a boot-critical driver should prevent startup.
  • Fewer blind spots during agent migrations: The provider, boot component and update path become verifiable.
  • Better changes: Driver dependencies and recovery are tested in practice, including on particularly sensitive AD systems.
  • An additional protection layer: ELAM strengthens the boot chain alongside Secure Boot, Code Integrity and ongoing endpoint protection.

Drawbacks and limits

  • Availability can suffer: A stricter selection can prevent legitimate systems from starting, particularly with unknown or boot-critical components.
  • Classification depends on the provider: “Good” does not guarantee freedom from defects; missing or invalid classification data can result in “Unknown”.
  • The default policy accepts residual risk: Boot-critical malware may be permitted so that the system can start. This case requires incident response.
  • No comprehensive driver control: Drivers loaded later, firmware risks and ordinary application execution need additional controls.
  • No GPO audit mode: Actual pilot startups and suitable diagnostics create operational work.
  • No repair of compromised systems: ELAM replaces neither root cause analysis nor a trustworthy rebuild.

Common pitfalls

  • Equating an Enabled GPO with additional hardening: The selected class determines whether more drivers are blocked than under the default.
  • Deploying Good only to every DC without testing: The same GPO encounters different storage, backup and security components.
  • Checking WdBoot after sign-in as though it were a continuously running service: Its expected unloading otherwise produces false alarms.
  • Presenting registry indicators as startup evidence: Policy, installed provider and successful protection during startup are separate verification points.
  • Confusing an antivirus signature update with a platform update: Both must match the intended product state.
  • Signing off a successful startup despite a malware finding: Availability and trustworthiness are separate decisions.
  • Planning rollback only through GPO: The offline recovery path must work before an outage occurs.

Project checklist

  • [ ] Define device classes and sensitive AD roles separately.
  • [ ] Document the ELAM provider, boot component, platform version and update path.
  • [ ] Check Windows support status, firmware and Secure Boot.
  • [ ] Inventory boot drivers and dependencies with product owners.
  • [ ] Back up the existing GPO and explicit administrative policy value.
  • [ ] Distinguish the default baseline from an actual increase in restrictions.
  • [ ] Define a separate pilot GPO, ownership and stop criteria.
  • [ ] Test the planned selection on representative hardware and virtual platforms.
  • [ ] Include restarts, relevant cold starts and routine updates in testing.
  • [ ] Change DCs one at a time and verify AD/DNS functionality after each change.
  • [ ] Make vendor diagnostics and detection alerts available for central analysis.
  • [ ] Test the console, WinRE and protected access to BitLocker recovery in practice.
  • [ ] Handle malware findings regardless of whether startup succeeded.
  • [ ] Document exceptions with affected devices, an owner, an expiry date and a return plan.
  • [ ] Revalidate after agent migrations and significant driver changes.