windows update failed with error 0x80070005 access denied

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.

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

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

Thread query: windows update failed with error 0x80070005 access denied

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.