Accountability usually spans IAM, messaging, security operations, and the business owners of the workflows that depend on email. If finance, HR, or IT approvals can be influenced by a forged message, those teams share responsibility for defining which messages require identity-backed protection and how exceptions are governed.
What makes email trust a shared accountability problem?
Email-based business trust sits at the point where technical controls and business process controls meet. No single team can own it end to end, because the risk appears when a message is allowed to influence a decision, move money, change vendor details, or approve access. That means the accountable parties are the teams that define trust rules, operate the mail and identity controls, and approve the workflow that relies on the message.
The practical question is not whether email is “secure enough” in the abstract, but which decisions are being accepted on the back of email. A forged request can become a business action only when a workflow treats the message as authoritative. That is why accountability often spans the workflow owner, IAM, messaging, and security operations.
Email trust also depends on who is allowed to vouch for the message. Strong sender authentication, mailbox protection, and approval controls matter because business trust is usually created by a combination of domain reputation, recognizable identities, and workflow expectations rather than by email alone. When those signals are weak or inconsistent, the business owner of the process shares responsibility for the risk that follows.
Where does accountability sit across IAM, messaging, and the business?
IAM is usually accountable for the identity side of the trust chain: who can send, approve, or act on behalf of a person or system, and what protections exist for identities that can influence email-linked decisions. Messaging or mail platform teams are accountable for email authentication, tenant security, and mailbox abuse controls. Business owners are accountable for deciding which emails are sufficient to trigger an action, and for defining when a second factor of verification is required.
That division matters because each team controls a different failure point. If the platform allows spoofing or mailbox takeover, the message itself is unreliable. If the business process accepts a single forged email as enough to pay an invoice or reset a workflow, the control failure is downstream of the mail system. Accountability should follow the point where the trust decision is actually made.
Email Identity and BEC Guide is useful here because it ties SPF, DKIM, DMARC, mailbox takeover, OAuth mail permissions, and payment verification back to the same trust problem. For identity abuse patterns that turn email into an access path, Microsoft verified publisher OAuth phishing 2022 shows how mailbox access can be gained without a simple password theft. Where stolen credentials are used to test or exploit trust, TruffleNet stolen AWS keys campaign 2025 reinforces that credential abuse often becomes business fraud after the trust boundary is crossed.
What does good accountability look like in practice?
Good accountability is explicit. The business owner should define which email requests can initiate action, what verification is required for exceptions, and what conditions trigger manual review. IAM should own the identity controls that reduce impersonation and mailbox abuse. Messaging and security teams should own the controls that make spoofing, token abuse, and unauthorized mailbox access harder to sustain.
NIST SP 800-207 Zero Trust Architecture is a useful lens because it pushes teams to verify trust claims instead of assuming that a message is safe because it came through email. For the underlying identity assurance problem, NIST SP 800-63 Digital Identity Guidelines supports stronger authentication expectations for the people and systems that can approve sensitive requests. If email trust is part of a broader security program, NIST Cybersecurity Framework 2.0 helps align govern, protect, detect, respond, and recover responsibilities around the same business process.
For organisations that need a more concrete control view, NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because the question sits at the intersection of identification, authentication, access control, auditability, and system integrity. In cloud environments, the same accountability split maps well to SPIFFE workload identity specification when service-level trust and message-triggered automation are part of the workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Email trust depends on who can authenticate into approval workflows. |
| AC-6 — Least Privilege | Limits who can act on email-triggered business requests and approvals. | |
| AU-2 — Event Logging | Email trust needs traceability for approvals, exceptions, and abuse investigations. | |
| Recommendation — Require strong user authentication before accepting email-driven approvals. Constrain email-linked actions to the minimum necessary privileges. Log email-triggered approvals and review events for accountability. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Email trust requires explicit ownership of business risk from forged messages. |
| PR.AA-05 — Identity Management, Authentication and Access Control | Email-based trust depends on authenticated identities behind sensitive requests. | |
| Recommendation — Assign risk owners for email-dependent workflows and exception paths. Apply identity and access controls before honoring high-impact email requests. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Mailbox-access abuse and consent phishing can undermine email trust. |
| V6 — Authentication | Strong authentication reduces the chance of mailbox takeover and impersonation. | |
| Recommendation — Harden OAuth consent and token handling for mail-connected applications. Use phishing-resistant authentication for users who can approve sensitive actions. | ||
Practitioner Guidance
What to verify: Confirm which workflows treat email as an approval signal, then check whether those workflows require identity-backed verification for high-impact actions such as payments, account changes, and access grants. If the answer is “not consistently,” the business owner is part of the control gap, not just the mail team.
Decision rule: If a forged or replayed message could trigger a material business action, require a second trust signal, such as authenticated workflow access, out-of-band confirmation, or tightly governed exception handling. Do not treat “known sender” as a sufficient control on its own.
What good looks like: The accountable owner of each email-dependent workflow is named, the mail and identity controls are documented, and exceptions are reviewable rather than informal. A mature setup can show who approved the control, who operates it, and who accepts residual risk.
Practitioner takeaway: Email trust is only “owned” when the organisation assigns responsibility at the workflow boundary, not just at the mail gateway. If a forged message can still move money, change access, or alter records, accountability is incomplete.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
- Why do browser-based prompt injections create a bigger trust problem than email summaries?