Who is accountable when phishing uses trusted infrastructure to deliver malicious email?

Accountability sits with the organisation’s layered email and identity controls, not with transport authentication alone. Security teams need shared ownership across messaging, identity, and endpoint functions because the threat spans all three. Governance should define how authenticated delivery, brand spoofing, and user exposure are jointly evaluated before the message reaches the inbox.

Why This Matters for Security Teams

When phishing rides on trusted infrastructure, the technical proof of delivery can look legitimate even while the message is malicious. That creates an accountability gap: mail flow teams may see authenticated transport, identity teams may see valid sender reputation, and endpoint teams only see impact after a user interacts. Current guidance suggests that responsibility must be shared across message authentication, identity assurance, and user-risk controls rather than assigned to transport alone. This is consistent with the broader direction of the NIST Cybersecurity Framework 2.0, which treats cyber outcomes as cross-functional.

NHI Management Group has documented how quickly attackers move once trust signals are weak or credentials are exposed in DeepSeek breach and The 2026 Infrastructure Identity Survey. That survey found that only 44% of organisations have policies to manage AI agents, despite 92% agreeing governance is critical, which is a useful signal of how often ownership lags the threat. In practice, many security teams discover the accountability problem only after a trusted sender path has already been used to deliver a successful lure.

How It Works in Practice

Trusted infrastructure phishing usually succeeds because an attacker borrows a legitimate delivery channel, then abuses gaps in message-level and identity-level verification. The mail may pass SPF, DKIM, or DMARC checks, but that does not mean the content is safe or that the originating workflow is authorised. The practical question is not only “was this message delivered?” but “who owned the control that should have blocked, quarantined, or flagged it?”

Operational accountability is usually divided across three functions:

• Messaging security owns sender authentication, spoofing controls, and filtering policy.

• Identity security owns the trust decisions that determine whether a sender, tenant, or service account should be allowed to communicate at that privilege level.

• Endpoint or user-risk teams own detection after delivery, including link analysis, attachment detonation, and response.

This division aligns with NIST Cybersecurity Framework 2.0 and with identity-focused guidance in NHI research. Where organisations fail is usually not in a single missing control, but in the absence of a clear decision tree for contested messages: authenticated does not equal trusted, and trusted does not equal safe. The right response is to define shared ownership for inbound abuse cases, set escalation thresholds, and require evidence of both transport legitimacy and content risk before delivery.

These controls tend to break down in large SaaS ecosystems with delegated sending, third-party mailers, or compromised service accounts because the trust boundary becomes distributed and harder to attribute.

Common Variations and Edge Cases

Tighter message verification often increases operational overhead, requiring organisations to balance stronger filtering against the risk of blocking legitimate business workflows. That tradeoff is especially visible when vendors, marketing platforms, or internal apps send on behalf of the organisation. Best practice is evolving here, and there is no universal standard for when a trusted sender should be treated as inherently low risk.

Two edge cases matter most. First, an attacker may not spoof the domain at all, but instead compromise a sanctioned sender or tenant, which shifts accountability from anti-spoofing controls to account hygiene, conditional access, and session monitoring. Second, a message may be fully authenticated but still malicious because the payload, link destination, or brand impersonation is the real abuse path. That means mail security cannot own the problem alone; policy must define when identity, content, and endpoint signals are combined into one verdict.

For governance, the practical standard is to assign one accountable owner for the decision process and multiple responsible teams for the control layers. That approach reflects current guidance better than assuming transport authentication is the final arbiter of trust. In high-volume environments, trusted infrastructure abuse is often found only after a user reports the lure or an endpoint alert reveals the compromise path.

Related resources from NHI Mgmt Group

• How should IAM teams respond when a trusted platform can deliver malicious messages?
• Who is accountable when a phishing email creates a persistent Microsoft 365 foothold?
• How should security teams handle phishing that arrives through trusted email infrastructure?
• Who is accountable when an employee uses an AI tool to trigger harmful access?