## TL;DR
0x80070005 is access denied inside the servicing path: the SYSTEM or TrustedInstaller context cannot write the component store, the SoftwareDistribution folder, or a registry key, typically after permissions were tightened by a hardening tool or an antivirus quarantined a servicing file. Check the CBS and WindowsUpdate logs for the denied path, restore default permissions on that path only, exclude servicing folders from third-party AV scanning, and retry.

```text
windows update failed with error 0x80070005 access denied
```

## Use this when
- Updates fail with 0x80070005 while signed in as administrator.
- The failure started after a hardening baseline or new antivirus rollout.
- DISM or SFC also report access errors.

## Not for this skill when
- A single user app install gets access denied. That is ordinary file permissions, not servicing.
- WSUS returns access denied to the console. That is IIS and console permissions, a different fix.

## Steps
1. Search WindowsUpdate.log (via Get-WindowsUpdateLog) and CBS.log for 0x80070005 and note the denied file, folder, or key. Verify: one concrete path is identified
2. Compare permissions on that path with a healthy machine; restore SYSTEM and TrustedInstaller full control where they were removed. Verify: the ACL matches the healthy reference
3. Temporarily disable or exclude third-party antivirus scanning of the SoftwareDistribution and WinSxS folders, then retry the update. Verify: the update installs with the exclusion in place, implicating the AV
4. Run DISM /Online /Cleanup-Image /RestoreHealth and sfc /scannow. Verify: both run to completion without access errors
5. Re-enable antivirus with the servicing exclusions kept. Verify: a later update still installs cleanly

## Variant phrasings
### windows update access denied 0x80070005
The plain phrasing without fix wording.
### 0x80070005 permissions component store
The root-cause phrasing for hardened images.
### subinacl windows update 0x80070005 legacy fix
The older phrasing from the Windows 7 era toolset; the modern fix is targeted ACL repair, not a blanket reset.

Compatibility: Compatibility: Windows 10, 11, and Server; log retrieval via Get-WindowsUpdateLog on modern builds.

## Why it happens
Servicing runs as SYSTEM and TrustedInstaller, not as the signed-in admin, so being an administrator does not override a broken ACL on servicing paths. Hardening scripts that recursively re-ACL the Windows folder, and antivirus products that lock files in the component store during scans, both produce exactly this failure.

## Edge cases / pitfalls
- Never take ownership of the entire WinSxS folder or reset all registry permissions; the blast radius is the whole servicing stack.
- If the denied path is in a user profile, the failing item is probably a per-user update component; treat that case separately.
- A Group Policy that denies the Windows Update service account logon rights produces the same code; check service logon policy on domain machines.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_naBw0TzOf8AsItmxDLdhpw