Who is accountable when a malicious extension reaches managed devices?

Accountability usually spans endpoint security, developer platform owners, and identity teams because the failure crosses publishing credentials, marketplace controls, and local execution. The organisation is accountable for deciding whether extension publishers are treated like privileged actors and whether auto-update is allowed without delay.

Why This Matters for Security Teams

A malicious extension is not just a software defect. It is a supply chain and privilege problem that reaches publishing credentials, marketplace trust, endpoint execution, and identity governance at the same time. When extension publishers can push updates into managed devices, the organisation has effectively granted them a path into user sessions and sometimes broader device context. NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and access control issue, not merely endpoint hygiene.

For NHI teams, the hard question is whether publisher accounts, signing keys, and update channels are being treated as privileged identities. That is where the risk becomes operational: a compromised extension ecosystem can bypass conventional app allowlists if trust is placed on the package name instead of the identity behind the release. NHIMG’s Top 10 NHI Issues and the Hard-Coded Secrets in VSCode Extensions research both show how extension ecosystems often hide identity and secret-management failures behind a developer productivity narrative. In practice, many security teams encounter the blast radius only after a trusted extension has already been updated and executed on managed endpoints.

How Accountability Is Assigned in Practice

Accountability usually falls across three control owners, but one function must own the decision model. Endpoint security owns execution controls on managed devices, developer platform owners own marketplace and signing workflows, and identity teams own publisher authentication, credential lifecycle, and revocation. The accountable risk owner is the team that decides whether publishers are treated as privileged actors and whether extension updates can execute without delay or review.

Current guidance suggests treating extension publishers and signing keys as non-human identities with explicit lifecycle controls. That means short-lived access where possible, strong authentication for release pipelines, and revocation processes that can cut off a compromised publisher quickly. This is where NHI lifecycle practices matter: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NHI Lifecycle Management Guide both emphasise inventory, rotation, offboarding, and visibility as the minimum foundation.

• Inventory all extensions, publishers, signing keys, and update channels.
• Map which teams approve publication, auto-update, and emergency revocation.
• Require identity proof for publishers, not just package reputation.
• Block or quarantine extensions that request excessive local permissions.
• Monitor for anomalous update behaviour and sudden privilege expansion.

NIST SP 800-53 Rev. 5 supports this by pushing organisations toward access enforcement, configuration control, and continuous monitoring rather than passive trust. These controls tend to break down when enterprise-managed devices allow silent auto-updates from externally controlled marketplaces, because the trust decision is delegated upstream and the local endpoint inherits the compromise instantly.

Common Variations and Edge Cases

Tighter extension governance often increases operational overhead, requiring organisations to balance developer productivity against revocation speed and review depth. That tradeoff becomes sharper in environments with frequent plugin refreshes, internal developer marketplaces, or mixed personal and managed devices.

There is no universal standard for this yet, but current guidance suggests that extensions used on managed devices should be classified by execution risk, not just by vendor name. A low-risk documentation add-on may not need the same treatment as an extension that can read files, inject code, or access browser sessions. For highly regulated environments, the safer posture is to delay auto-update for high-risk extensions until integrity checks and allowlist validation complete. For organisations already using zero trust or strong application control, this can be integrated with device posture and policy-as-code, but the policy must still answer who can publish, who can revoke, and who accepts the risk of a compromised update stream.

Where teams usually get it wrong is assuming endpoint telemetry alone can prove accountability. Telemetry shows impact; it does not assign ownership of the signing credential, publisher account, or marketplace process. NHIMG’s Ultimate Guide to NHIs – Regulatory and Audit Perspectives is a useful reminder that auditors will ask for lifecycle evidence, not just detection evidence. The question is less about who noticed the malicious extension and more about who was responsible for preventing a trusted publisher from becoming the attack path.

Related resources from NHI Mgmt Group

• Who is accountable when a malicious extension or fake AI tool steals credentials from managed endpoints?
• Who is accountable when a malicious OTA update reaches production devices?
• What breaks when a malicious developer extension reaches repository access on a managed workstation?
• How should teams reduce risk from malicious npm package installs?