Who is accountable when phishing files lead to code execution?

Why This Matters for Security Teams

When a phishing file reaches execution, the issue is not just email hygiene. It becomes a cross-control failure that can turn a single user interaction into system compromise, lateral movement, or credential theft. That means accountability sits across the mail gateway, endpoint controls, identity protections, and the business process that allowed the file to matter in the first place. NIST SP 800-53 Rev. 5 makes this boundary explicit through layered controls, not single-point blame.

For NHI-heavy environments, the same pattern appears with tokens, service accounts, and automation keys. NHIMG’s Ultimate Guide to Non-Human Identities notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which shows how quickly initial access becomes operational loss. Phishing payloads often aim to harvest exactly those secrets or exploit the workstation to reach them. In practice, many security teams encounter accountability only after code execution has already occurred, rather than through intentional boundary design.

How It Works in Practice

Accountability should follow control ownership, not the last team to notice the alert. If a malicious attachment executes code, email security owns inspection and detonation controls, endpoint security owns execution prevention and containment, and the application or workflow owner owns the exposure created by local trust, over-permissioned access, or unsafe file handling. NIST guidance supports this shared model because no single control is sufficient once a payload crosses from delivery into runtime.

Practically, teams should map the path from inbox to process execution:

• Email security: attachment filtering, sandboxing, URL rewriting, and macro controls.
• Endpoint security: application allowlisting, script controls, exploit protection, and host isolation.
• Identity security: privilege reduction, phishing-resistant authentication, and rapid token revocation.
• Workflow ownership: identify where user-writable files can trigger code, jobs, or automation.

That same workflow lens matters for non-human identities. If a phishing payload steals secrets from a developer machine or CI runner, the blast radius often includes API keys, cloud tokens, or service account credentials. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio and Gemini CLI Breach - Silent Code Execution illustrate how code execution can be a stepping stone to identity compromise, not just endpoint compromise. Current guidance suggests treating the accountable owner as the team responsible for the control gap that let the attachment execute and persist, then tracing secondary impact to identity and data owners. These controls tend to break down when users can launch code from unmanaged endpoints or when local privileges allow malware to bypass containment before telemetry is collected.

Common Variations and Edge Cases

Tighter email and endpoint controls often increase operational friction, requiring organisations to balance user productivity against prevention depth. That tradeoff is especially visible in engineering, finance, and research groups where file-based workflows are normal and false positives can be costly.

There is no universal standard for this yet, but current guidance suggests three common edge cases. First, if the file only delivered a payload but execution happened because of a weakened host policy, endpoint ownership is primary. Second, if the file exploited a business-approved workflow, such as document automation or macro-enabled processing, the workflow owner shares accountability because the business process created the condition for execution. Third, if the compromised endpoint exposed secrets, the identity team must be involved even when the phishing itself was not an identity event.

Use the same logic in post-incident reviews: identify the failing control, assign remediation to the control owner, and separate technical blame from governance accountability. For broader resilience, align the response with NIST SP 800-53 Rev 5 Security and Privacy Controls and the NHIMG view of shared NHI exposure in the Ultimate Guide to Non-Human Identities. The hard cases are unmanaged endpoints, BYOD laptops, and embedded file-processing automations, because those environments collapse the boundary between user action, host execution, and identity exposure.

Related resources from NHI Mgmt Group

• How should security teams reduce the risk of clipboard-based phishing leading to code execution?
• What should organisations do after a developer tool is shown to allow arbitrary code execution?
• Who is accountable when an AI agent reads restricted files through a bypass?
• Who is accountable when an update infrastructure breach exposes users to malicious code?