Use this document as the canonical security view of the baseline.

It describes the security posture, threat boundaries, assumptions, and trade-offs for the supported baseline: Windows 11 Enterprise LTSC 2024 workstations (EditionID=EnterpriseS or IoTEnterpriseS, 24H2, build 26100+) in standalone or simple network environments without corporate integration or automatic proxy discovery requirements.

The baseline uses native Windows configuration mechanisms and system-recognized states, validated by project testing. It avoids binary patching, ACL weakening, and invasive component changes, while favoring deterministic behavior and idempotent operations where the component contract supports them.

• SmartScreen policy layers are disabled for Windows Shell and Edge.
• Microsoft Defender Antivirus remains enabled. Real-time protection, On-Access protection, IOAV protection, applicable NIS protection, and PUA protection remain enabled, while Tamper Protection is intentionally Off in the prepared deployment and Behavior Monitoring is intentionally disabled through persistent Local GPO records. The policy-backed threat action for 2147741622 protects that materialization during Defender Security Intelligence reevaluation. The baseline applies machine policy to disable cloud/MAPS participation and automatic sample submission and reports when the effective privacy posture cannot be verified.
• Delivery Optimization is set to mode 0 (HTTP-only, no peer-to-peer).
• Windows Update runs in notify-only mode. ExcludeWUDriversInQualityUpdate=1 excludes driver offers delivered through quality updates; preview builds, other Microsoft products, and OS upgrade offers are not requested by this baseline.
• WPAD is disabled via policies on WinINET and WinHTTP. The WinHTTP Auto-Proxy service is not forcibly disabled.
• Edge first run experience is suppressed via policy (HKLM\SOFTWARE\Policies\Microsoft\Edge\HideFirstRunExperience=1) to reduce extra first-boot prompts and calls.
• The baseline does not invoke DISM /Online /Cleanup-Image /StartComponentCleanup or /ResetBase automatically. Any aggressive component cleanup that removes rollback for installed updates is considered an optional, operator-driven hardening step and is not part of the core pipeline.
• Several hardening steps rely on disabling selected optional Windows features via DISM. State-aware optional-feature handling skips features already Disabled, treats a recognized feature-not-found result as absent and skips it, and disables only features proven Enabled. Unexpected feature-probe failures or states that do not prove Enabled or Disabled fail closed. Other unexpected servicing failures remain fatal and do not silently weaken the baseline.
• The baseline attempts to disable SysMain, WSearch, Spooler, DiagTrack, dmwappushservice, WerSvc, WebClient, and Xbox services (XblGameSave, XboxGipSvc, XboxNetApiSvc), affecting search indexing, printing, WebDAV, Xbox functionality, and background activity. It also attempts to restrict Remote Assistance, disable hibernation and Fast Startup, and activate the Ultimate Performance power plan. Service and Remote Assistance failures produce hardening warnings; power-setting failures are logged as warnings. The state-aware DISM path attempts to disable SMB1Protocol, MicrosoftWindowsPowerShellV2, Printing-XPSServices-Features, WorkFolders-Client, MSRDC-Infrastructure, WindowsMediaPlayer, TelnetClient, and TFTP when verified as enabled; unexpected DISM failures remain fatal.

This baseline does not attempt to disable Microsoft Defender Antivirus. Real-time protection, On-Access protection, IOAV protection, applicable NIS protection, and PUA protection remain enabled. Tamper Protection is intentionally Off in the prepared deployment, and Behavior Monitoring is intentionally disabled through the persistent Local GPO baseline. The payload also carries the policy-backed threat action 2147741622 with action 6 for VirTool:Win32/DefenderTamperingRestore; this protects the materialized Behavior Monitoring policy without adding a runtime repair mechanism. ConfigureDefenderPrivacy.ps1 remains the single runtime owner of the machine-policy values SpynetReporting=0 and SubmitSamplesConsent=2.

Successful registry mutation is not treated as proof that Defender currently honors the intended posture. The component separately observes IsTamperProtected and verifies effective MAPSReporting=0 and effective SubmitSamplesConsent=2; for this privacy component's result only, either observed Tamper Protection value is compatible with successful privacy verification. Overall deployment acceptance separately requires Tamper Protection Off. Tamper Protection is observed but never disabled or bypassed by this component. A genuine effective MAPS/sample mismatch, technical component failure, or missing runtime component becomes a non-fatal hardening warning in SetupComplete.cmd; it is not by itself a trusted-continuation failure.

Windows Security may visibly warn when Tamper Protection is Off. This warning is independent of the baseline's intentional Behavior Monitoring disablement and does not indicate that Microsoft Defender Antivirus or the explicitly retained real-time, On-Access, IOAV, NIS, and PUA protections have changed.

The two Defender privacy values are written directly to the machine policy registry, not to Local GPO Registry.pol. The corresponding privacy Administrative Template settings may therefore appear as Not Configured in gpedit.msc even when both the registry policy and Defender effective state are correct. This direct path is separate from the BaselinePolicies.txt Local GPO declarations; the payload's Computer records are the persistent authority for Behavior Monitoring and the 2147741622 threat-remediation exception. The policy-backed state is distinct from the transient runtime/history path HKLM\SOFTWARE\Microsoft\Windows Defender\Threats\ThreatIDDefaultAction, and the baseline adds no scheduled reapplication or watchdog.

The exact image selected for installation must be prepared offline with HKLM\SOFTWARE\Microsoft\Windows Defender\Features\TamperProtection=REG_DWORD 4. Existing ACLs must be preserved, and TamperProtectionSource is not synthesized. The preparation is an operator-owned media boundary and requires an authority able to modify the protected offline key; it is not a runtime Tamper bypass. The offline Tamper preset is project-validated; explicit Microsoft documentation for this exact provisioning method has not been established. See Operations for the invariant and practical procedure.

SmartScreen is disabled for Windows Shell and the Edge policy layer to minimize silent outbound reputation/data flows. Those settings remain enforced through registry policy and orchestration in SetupComplete.cmd.

The Windows Security notification-area presentation is suppressed through the supported machine policy HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Systray\HideSystray=1. SetupComplete.cmd also removes only the standard machine-wide HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SecurityHealth autorun entry for %windir%\system32\SecurityHealthSystray.exe. This is presentation and autorun cleanup only; this suppression does not disable or otherwise modify Windows Security, SecurityHealthService, wscsvc, WinDefend, or the explicitly retained Defender protections. Behavior Monitoring remains the separate intentional Local GPO disablement.

Edge browser removal runs early in SetupComplete.cmd as a best-effort hardening layer. Edge SmartScreen policies are still set to disabled before removal, EdgeUpdate services/tasks are left unchanged, and WebView2 runtime is not removed.

On Windows 11 IoT Enterprise LTSC 2024, the standard Microsoft Edge uninstaller may block removal, leaving the browser installed. LTSC-clean logs this as a non-blocking hardening warning and continues deployment.

• Windows Shell SmartScreen: HKLM\SOFTWARE\Policies\Microsoft\Windows\System\EnableSmartScreen=0
• Edge SmartScreen policies: HKLM\SOFTWARE\Policies\Microsoft\Edge\SmartScreenEnabled=0; HKLM\SOFTWARE\Policies\Microsoft\Edge\SmartScreenDnsRequestsEnabled=0; HKLM\SOFTWARE\Policies\Microsoft\Edge\SmartScreenForTrustedDownloadsEnabled=0; HKLM\SOFTWARE\Policies\Microsoft\Edge\SmartScreenPuaEnabled=0
• Retained Defender protections: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableRealtimeMonitoring=0; HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableIOAVProtection=0; HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\PUAProtection=1; Behavior Monitoring is intentionally disabled by the Local GPO Computer record DisableBehaviorMonitoring=1 and protected by the policy-backed 2147741622 action 6
• Defender cloud/privacy policy: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet\SpynetReporting=0; HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet\SubmitSamplesConsent=2
• Edge lifecycle: early best-effort uninstall via Edge setup.exe --uninstall --system-level --force-uninstall; EdgeUpdate services/tasks left unchanged; WebView2 not removed
• UX hygiene: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\DisableEdgeDesktopShortcutCreation=1

• SmartScreen prompts or Defender cloud protection by policy.
• Tamper Protection or Behavior Monitoring enabled as the baseline state.
• Peer-to-peer Delivery Optimization or Connected Cache scenarios.
• Automatic proxy discovery (WPAD) for WinHTTP clients.
• Guaranteed rollback of currently installed updates.
• Enterprise hardening stacks enabled by default (for example, MDE onboarding, WDAC, AppLocker, BitLocker enforcement, LAPS, or domain-based baselines).
• Disabled or lowered UAC behavior.

• Use least-privilege accounts for daily work; avoid local admin where possible.
• If a proxy is introduced later, configure it explicitly: netsh winhttp set proxy or a supported policy. With WPAD disabled, auto-discovery will not occur.
• Consider periodic offline AV scans or a trusted third-party endpoint if organizational policy requires it.
• If you add Attack Surface Reduction (ASR) rules to the existing Defender local-protection posture, test them on a VM first.

The baseline uses a fail-closed platform compatibility posture by default. Best-effort compatibility is an explicit opt-out for forks or experiments and carries the risk that some steps may not apply or may behave differently on nearby Windows versions.

The operator must stage a trusted Microsoft LGPO.exe at %WINDIR%\Setup\Scripts\LGPO.exe. SetupComplete.cmd executes that binary as SYSTEM to import the repository-tracked %WINDIR%\Setup\Scripts\BaselinePolicies.txt payload.

The runtime pipeline does not acquire, download, version-check, hash-check, or Authenticode-check LGPO.exe. The ISO Builder verifies the supplied binary's Microsoft Authenticode signature during media preparation. Selecting and supplying the trusted binary remains an operator responsibility. Missing inputs or a non-zero import result fail closed before the normal baseline workload continues.

The non-admin tamper-boundary validation used later for Stage B preparation does not validate LGPO.exe before this early import and must not be treated as doing so.

The baseline writes technical logs to %WINDIR%\Panther\PreOOBE.log and %WINDIR%\Panther\SetupComplete.log. DISM activity, when used, is additionally recorded in %WINDIR%\Logs\DISM\SetupComplete-DISM.log.

These logs are intended for technical review and do not intentionally include password values or derived secrets. BootstrapLocalAdmin.ps1 emits structured lifecycle messages into PreOOBE.log without logging the bootstrap password, and the baseline does not intentionally place primary-admin secrets in command lines, task definitions, or intentional log output.

Set retention and deletion of these logs according to your environment's policy.

Part of the baseline's privacy and account hardening is applied early, during specialize, through PreOOBE.cmd.

This includes suppression of the privacy experience, disabling of selected telemetry- and personalization-related features, and disabling local password reset questions.

Applied controls include:

• HKLM\SOFTWARE\Policies\Microsoft\Windows\System\NoLocalPasswordResetQuestions=1
• HKLM\SOFTWARE\Policies\Microsoft\Windows\OOBE\DisablePrivacyExperience=1
• HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry=0
• HKLM\SOFTWARE\Policies\Microsoft\Windows\AdvertisingInfo\DisabledByGroupPolicy=1
• HKLM\SOFTWARE\Policies\Microsoft\InputPersonalization\AllowInputPersonalization=0
• HKLM\SOFTWARE\Policies\Microsoft\Windows\LocationAndSensors\DisableWindowsLocationProvider=1
• HKLM\SOFTWARE\Policies\Microsoft\Windows\LocationAndSensors\DisableLocation=1
• HKLM\SOFTWARE\Policies\Microsoft\FindMyDevice\AllowFindMyDevice=0

Effect: the privacy wizard is suppressed, the corresponding privacy-related toggles are enforced off, and local-account security questions are disabled.

Tailored experiences are disabled separately through the User Local GPO record Software\Policies\Microsoft\Windows\CloudContent\DisableTailoredExperiencesWithDiagnosticData=1 in BaselinePolicies.txt.

AutoAdminLogon requires HKLM\...\Winlogon\DefaultPassword (REG_SZ). In this baseline, that value is used only temporarily, during the priming-to-first-bootstrap-logon window.

Only the temporary bootstrap password is ever written to DefaultPassword. The primary admin password is never stored there. It remains in .primaryadmin.pw, is validated before use, and is read directly under SYSTEM by CreatePrimaryAdmin.ps1, so the \L2C\CreatePrimaryAdmin task definition and command line contain no password arguments.

Risk mitigations:

• on the verified normal teardown path, the temporary bootstrap password is removed from Winlogon after the first logon path is finalized; if cleanup cannot be verified, recovery state may be retained;
• SetupComplete.cmd arms autologon only after the relevant gate checks succeed;
• if autologon priming or its non-secret marker handling fails, the baseline rolls back or falls back to manual continuation rather than silently leaving an unsafe state;
• if Winlogon cleanup verification fails, teardown is suppressed and recovery posture is preserved instead of claiming normal completion;
• logs do not intentionally include password values.

The baseline uses two temporary on-disk secrets during provisioning: .bootstrap.pw and .primaryadmin.pw in %WINDIR%\Setup\Scripts.

Both secrets are treated as hardened local files: inheritance must be disabled, access must be restricted to NT AUTHORITY\SYSTEM and the local Administrators group, and the files must carry the expected protected attributes. Secret validation is fail-closed: if required ACL or attribute checks fail, if required content validation fails, or if the relevant gate conditions are not met, autologon and Stage B registration do not proceed normally. Secret validity and local-account usability are separate continuation preconditions.

.bootstrap.pw provides the temporary bootstrap password used only for the first-logon transition. .primaryadmin.pw provides the primary admin password, is operator-supplied rather than generated by the baseline, and is never placed in task arguments or command lines. CreatePrimaryAdmin.ps1 reads it directly under SYSTEM.

At the start of Stage B continuation preparation, SetupComplete.cmd independently verifies exactly one local bootstrap account with a readable Boolean Enabled=$true state before task-directory hardening, task registration, temporary logon-policy writes, or Winlogon autologon priming. Missing, disabled, ambiguous, unreadable, or otherwise unproven account state closes the existing failure/recovery gate. SetupComplete.cmd does not repair or re-enable the account, and a retained .bootstrap.pw proves only that the file passed its own checks; it does not prove that bootstrap is usable for another continuation attempt.

In the normal success path, after TeardownEligible and independently verified executor teardown, the temporary executor state is removed and both secret files are deleted. Outside that path, secrets may be preserved deliberately for recovery, investigation, or retry rather than being silently discarded.

• Path and ownership: %WINDIR%\Setup\Scripts\.primaryadmin.pw, supplied by the operator either manually or through the ISO Builder. The runtime baseline scripts only read and later delete it on the normal success path (otherwise it is preserved for retry).
• Format and encoding: UTF-8 without BOM. The file is treated as a single-line secret; the first line must be non-empty and may contain only A-Z, a-z, 0-9, #, @, _, and -. Whitespace or other characters are invalid. A trailing end-of-line after the password is fine; leading blank lines render the secret unusable.
• Content rules: the file is treated as a single-line secret. SetupComplete.cmd passes only the file path to its shared :validate_password_file helper; Windows PowerShell 5.1 reads the first line directly via Get-Content -TotalCount 1, checks the character policy above, and returns only a normalized status to CMD (0 valid, 1 invalid, 2 empty or unreadable). Raw password contents are not stored in CMD variables or passed as command-line arguments for format validation. Stage A of CreatePrimaryAdmin.ps1 reads only the first line via Get-Content -TotalCount 1 and trims the trailing end-of-line. Missing files, empty files, or first lines that are empty or whitespace-only are treated as unusable and keep the gate closed. Additional lines after the first are ignored; this does not weaken security but can mislead operators if the password is placed on a later line.
• ACLs and attributes: inheritance disabled; explicit FullControl for NT AUTHORITY\SYSTEM and local Administrators only; Hidden+System attributes. If this required shape is not present, the baseline treats the secret as invalid and does not read it for privileged continuation.
• Consumption and lifecycle: SetupComplete.cmd validates .primaryadmin.pw content only after the required ACL and attribute checks succeed; if the file is missing, unreadable, empty, or contains unsupported characters, the combined gate fails and autologon / Stage B registration are skipped. Stage A of CreatePrimaryAdmin.ps1 re-reads the file under SYSTEM and aborts if it cannot load or validate the password. The \L2C\CreatePrimaryAdmin task contains no password or secret arguments, and the primaryadmin password is never passed to net.exe; it is applied via Microsoft.PowerShell.LocalAccounts (New-LocalUser / Set-LocalUser with a SecureString) inside Stage A. In the normal success path, both .bootstrap.pw and .primaryadmin.pw are deleted; outside that path, they may be preserved for investigation or retry.
• Consequences: the primary admin password is never generated or guessed by the baseline; logs never contain the password itself, only validation outcomes; failure to read or validate .primaryadmin.pw stops unattended primary admin provisioning instead of silently weakening security.

The ISO Builder creates .primaryadmin.pw from the operator-entered password and embeds it in the prepared Windows image. The resulting ISO contains this password and must be kept private, including after installation. Deleting the secret from the installed system does not remove it from the installation ISO.

• For the long-lived primary admin (primaryadmin), the password is never placed on any process command line and does not appear in Windows Security 4688 process creation events even when command-line logging is enabled. The baseline does not intentionally log this password anywhere. The value lives only in .primaryadmin.pw (Hidden+System, inheritance disabled, explicit SYSTEM + local Administrators ACL) and is applied via Microsoft.PowerShell.LocalAccounts (New-LocalUser/Set-LocalUser with a SecureString) inside CreatePrimaryAdmin.ps1; no net.exe user <password> calls remain.
• Stage A failure handling remains fail-closed and observable: if user provisioning fails after Stage A created primaryadmin during this run, Stage A attempts best-effort rollback via Remove-LocalUser and throws, forcing recovery mode; if the account already existed, Stage A throws without deleting the user. Recovery mode preserves secrets and the bootstrap account so the operator can investigate and retry.
• The temporary bootstrap administrator password is set during the early PreOOBE phase by BootstrapLocalAdmin.ps1 using Microsoft.PowerShell.LocalAccounts cmdlets with a SecureString password, so BootstrapLocalAdmin.ps1 does not pass the password as an argument on an external process command line (mitigating exposure in Security 4688 command-line auditing and EDR/telemetry). This is still a short-lived account. In verified normal teardown, Stage B disables it and removes the continuation machinery; failure and recovery paths may intentionally retain bootstrap-related recovery state rather than claim normal completion, and partial executor mutations are not rolled back. If hardening of %WINDIR%\Setup\Scripts\.bootstrap.pw fails, the baseline treats the bootstrap secret as unusable, keeps the gate closed, and does not register Stage B.
• Password values never appear in Task Scheduler definitions or intentional logs; the hardened on-disk secrets (.bootstrap.pw and .primaryadmin.pw) use Hidden+System attributes and explicit SYSTEM + Administrators ACLs, and the temporary bootstrap password is also held in Winlogon DefaultPassword only during the priming-to-first-bootstrap-logon window.
• Attempts to weaken those secrets (extra ACEs, inheritance enabled, missing attributes, deleting or emptying .primaryadmin.pw, or using unsupported characters) cause SetupComplete.cmd to fail closed: no temporary autologon, no Stage B registration, and an exit that requires interactive follow-up using the logs.
• When Stage B reaches secret cleanup and the relevant master-log evidence is successfully persisted, the master log records one cleanup state per secret (removed, missing, error, preserved, or skipped). An earlier exception before those states are established or appended, or a master-log persistence/finalization failure, can leave the master log absent, incomplete, or present without one or both records; the master log is authoritative only for records it actually contains, and an absent record does not prove any cleanup outcome. An actually recorded cleanup state=error remains a security-significant deviation: secrets may remain on disk, the run is forced to FAIL, and automatic reboot is suppressed.
• TOCTOU and local administrators/SYSTEM: secret ACL and content checks happen at discrete points in the pipeline (ValidateSecrets.ps1 in SetupComplete, the gate logic in SetupComplete.cmd, and Stage A of CreatePrimaryAdmin.ps1). Note: .bootstrap.pw creation itself avoids the write-then-ACL TOCTOU window by applying the intended DACL at creation time and verifying it fail-closed. A local administrator or code running as SYSTEM can still modify .bootstrap.pw or .primaryadmin.pw between later steps. This is an accepted TOCTOU limitation: the baseline does not attempt to protect against an attacker who already has local administrator or SYSTEM privileges on the machine; its goal is to prevent misconfiguration and secret leakage on otherwise trusted hosts.

The \L2C\CreatePrimaryAdmin task runs as SYSTEM so Stage A can apply secrets without passing passwords on task arguments. This baseline does not attempt to defend against attackers who already have local administrator or SYSTEM rights.

Correct operator staging of the repository-tracked runtime payload into the supported installation image is the deployment trust-root assumption; it does not make arbitrary files under %WINDIR%\Setup\Scripts trustworthy. SetupComplete.cmd and its staged ValidateSecrets.ps1 component execute inside the current trusted orchestration boundary, so the runtime does not recursively authenticate those currently executing components. CreatePrimaryAdmin.ps1 is also trusted when staged, but it is executed later as SYSTEM after SetupComplete.cmd finishes. The four ACL checks below protect the surfaces that must remain trustworthy across that delayed handoff. Initial compromise or malicious replacement of the staged deployment payload is outside this runtime non-admin tamper model.

For the non-admin boundary, ValidateSecrets.ps1 proves trusted authority rather than maintaining a list of known-bad principals. It validates these four trust objects:

• %WINDIR%\Setup\Scripts (directory)
• %WINDIR%\Setup\Scripts\CreatePrimaryAdmin.ps1 (file)
• %SystemRoot%\System32\Tasks\L2C\CreatePrimaryAdmin (task definition file)
• %SystemRoot%\System32\Tasks\L2C (directory)

Each object must have a trusted owner: SYSTEM (S-1-5-18) or BUILTIN\Administrators (S-1-5-32-544). Owner resolution failure, an untrusted owner, a missing owner, or an unreadable/unprovable security descriptor fails closed.

An applicable Allow ACE that grants write-like authority is acceptable only for these exact trusted writer anchors: SYSTEM (S-1-5-18), BUILTIN\Administrators (S-1-5-32-544), or the exact NT SERVICE\TrustedInstaller service SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464). Other service SIDs, local users or groups, domain principals, and names that merely appear privileged are not trusted writer anchors. An unresolved write-capable trustee therefore fails closed; an unresolved read-only trustee may remain acceptable when its rights are provably non-write-capable.

Explicit and inherited ACEs are evaluated the same way when they apply to the current object. An ACE with InheritOnly propagation applies only to descendants and is not authority over the current object; this permits the stock inheritance-only CREATOR OWNER GenericAll ACE on the Scripts directory without adding CREATOR OWNER to the trusted writers. Read-only access does not violate this boundary, including untrusted ReadAndExecute grants and the explicit SYSTEM:Read task-file ACE.

SetupComplete.cmd hardens %SystemRoot%\System32\Tasks\L2C before task creation and validates this boundary before and after task registration.

Unsafe rights for this boundary include WriteData, AppendData, WriteAttributes, WriteExtendedAttributes, Delete, DeleteSubdirectoriesAndFiles, ChangePermissions, and TakeOwnership, as well as broader Write, Modify, or FullControl grants and raw GENERIC_WRITE or GENERIC_ALL access-mask bits. Synchronize alone is not treated as unsafe for this boundary. The validator uses SID-native access-rule enumeration, rejects a null or absent DACL, and does not attempt exact ACL-template matching or effective-access/token simulation.

Enforcement is fail-closed: if trusted ownership, security-descriptor state, or applicable write authority is unsafe or cannot be proven safe, the boundary check fails, normal continuation is not trusted, and the result is recorded in %WINDIR%\Panther\SetupComplete.log.

The existing Windows system Scripts tree is validated in place rather than normalized, while the Tasks\L2C task directory is explicitly established and hardened by SetupComplete.cmd before task creation. Focused Windows PowerShell 5.1 tests and a fresh Windows 11 Enterprise LTSC 2024 deployment accepted the stock ACLs; replaying an explicit ordinary non-admin Modify ACE on CreatePrimaryAdmin.ps1 changed the pre-check result from the former RC=0 to RC=16.

During priming:

• DisableCAD=1
• DevicePasswordLessBuildVersion=0
• IgnoreShiftOverride=0 (enforced separately as REG_SZ)

On rollback or restore:

• DisableCAD=0
• IgnoreShiftOverride=0 (REG_SZ)
• DevicePasswordLessBuildVersion=2 in the normal Stage B path; 0 in the recovery Stage B path

The restore guarantee is provided by the idempotent logic in CreatePrimaryAdmin.ps1.

Safety invariant: after TeardownEligible is true (normal mode and required logon-policy/Winlogon restore verifications), Stage B may attempt executor teardown by disabling bootstrap and deleting the \L2C\CreatePrimaryAdmin task, but executor teardown is not considered complete unless final state is independently verified: bootstrap is disabled and the continuation task is absent. Secret deletion and normal success remain blocked if those postconditions are false or unproven.

In the normal path, verified restore plus verified executor teardown allows normal success and cleanup to proceed. Mutation return codes are diagnostic evidence, not proof of final state. If teardown is not eligible, executor mutations are not attempted and the bootstrap/task recovery posture and secret files are retained. If teardown is eligible but executor verification is false or unproven, secret deletion, normal success, and the post-success reboot are blocked; the secret files are preserved, but executor state may already be partially changed and is not rolled back, so actual final state must be independently observed. A later cleanup failure may likewise leave already-verified executor teardown in place while blocking normal success and reboot.