They separate the request from a verifiable identity signal, so the recipient cannot reliably tell whether the instruction came from the authorised business actor. That makes spoofing, impersonation, and false acceptance more likely. A secure workflow should bind identity, request, and authorisation together so the approval itself is verifiable.
Why the approval channel matters as much as the approval itself
Email and phone approvals are risky because the channel can be copied, forwarded, redirected, spoofed, or socially engineered long before the business request is actually verified. If the approval path does not bind the message to a known identity, the recipient is judging tone and context instead of trustworthiness, which is exactly where false acceptance starts.
That problem is not limited to obvious fraud. A legitimate-looking message can be replayed from a compromised mailbox, delivered from a look-alike address, or paired with a convincing phone call that substitutes persuasion for proof. The workflow may feel fast, but speed is not evidence of authorisation.
A stronger design ties the request to an authenticated business identity, a specific action, and a recorded approval state so the recipient can verify what was asked, who asked for it, and whether that party was allowed to ask.
How spoofing, impersonation, and false acceptance happen
The core weakness is separation. In a healthy approval process, identity, request content, and authorisation evidence stay connected. In email and phone-based approvals, those elements are often split across a mailbox thread, a voicemail, or a callback number that may not be independently trustworthy.
Once the link is broken, the attacker only needs one convincing surface. That may be a forged sender display name, a compromised account sending from a real domain, a number that appears familiar, or a conversation that pressures the recipient to act quickly. The victim is no longer validating the business rule, only the social signal.
This is why these channels are attractive for payment redirection, invoice fraud, vendor-bank-detail changes, and urgent exception requests. They let the attacker borrow routine communication patterns while avoiding stronger verification steps that would expose the deception.
For teams that want to reduce that exposure, NHIMG’s Email Identity and BEC Guide is useful because it treats email impersonation as a trust problem, not just a filtering problem.
What a verifiable approval workflow looks like in practice
A trustworthy workflow makes the approver prove identity through the same system that records the action, rather than asking the recipient to infer identity from an inbox or a call. That usually means using a controlled request system, strong authentication, explicit approver attribution, and an immutable approval record tied to the transaction.
The practical test is simple: if the approver later denies the request, can the business show who approved it, from where, under what policy, and for which exact transaction? If the answer is no, the approval process is too weak for high-risk requests.
Exception handling matters too. If a request arrives by email or phone but the consequence is material, the workflow should force a second-channel verification or a return to the controlled system. Ad hoc approval may be tolerable for low-impact coordination, but it should not be the final authority for sensitive actions.
Where approval leads to privileged or irreversible action, NHIMG’s Just-in-Time Access and Zero Standing Privilege Guide helps frame the approval as a bounded authorisation event rather than a standing permission.
Why this becomes an identity and trust problem at scale
As approval volume grows, informal channels become harder to police and easier to weaponise. Teams start to rely on recognition, urgency, and habit, which makes the organisation more vulnerable to mailbox compromise, social engineering, and executive impersonation. The risk is not just a bad decision, but a decision made under a false trust assumption.
Scale also creates inconsistency. One manager may call back, another may not. One team may require ticket evidence, another may accept a reply-all confirmation. That inconsistency gives attackers room to target the weakest path and makes post-incident review difficult because there is no single verifiable standard.
Approvals that affect money, access, customer data, or vendor relationships need the same discipline as any other control boundary. If the approval cannot be independently verified, it is only a communication, not an authorisation.
For broader fraud patterns that exploit that weakness, NHIMG’s Top 10 Online Fraud Attacks provides a useful reference point for how business email compromise and impersonation tactics fit into real fraud workflows.
Risk and Threat Considerations
Email and phone approvals create a trust gap because the recipient is asked to accept authority without a strong cryptographic or system-backed proof of who is issuing the request. That increases the chance of spoofing, impersonation, replay, and accidental approval of a fraudulent instruction.
Failure mechanism: The attacker abuses a channel that looks familiar but is not itself a reliable trust anchor, then uses urgency or authority cues to bypass normal verification.
Impact: The organisation may execute an unauthorised payment, grant access, change bank details, or approve a sensitive exception based on a false belief that the request was legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Email and phone approvals fail when identity cannot be reliably verified. |
| NHI-05 — Overprivileged NHI | High-impact approvals should not rely on broad, informal authority paths. | |
| Recommendation — Require a verifiable approval path before any sensitive action proceeds. Limit approval authority to the minimum needed for the transaction. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Approvals need a trusted identity signal for organisational decision-makers. |
| AC-6 — Least Privilege | Approval paths should not grant broad standing authority by default. | |
| AU-2 — Event Logging | Verifiable approvals require an auditable record of who approved what and when. | |
| Recommendation — Authenticate approvers before accepting high-impact instructions. Restrict approval powers to narrowly defined, justified access. Log approval identity, action, timestamp, and transaction details. | ||
Practitioner Guidance
What to verify: Treat the approval channel as untrusted unless the request is tied to a verified identity, a specific transaction, and a recorded policy decision. If any one of those three is missing, the approval should not be treated as complete.
Decision rule: If the request can change money, access, credentials, vendor details, or other high-impact state, require a system-mediated approval path or a separate verification step, not a reply email or a callback alone.
Common mistake: Teams often harden email delivery or call screening and then assume the approval itself is trustworthy. That improves delivery hygiene, but it does not solve the core problem of proving who authorised the action.
Practitioner takeaway: The safest approval is the one that can be independently audited after the fact, because trust based only on channel familiarity is easy to fake and hard to defend.
Related resources from NHI Mgmt Group
- Why do email-based access approvals create governance risk?
- Why do phone fraud phishing attacks create broader risk than executive-focused business email compromise?
- Why do email-based access approvals create more risk than collaboration-channel approvals?
- Why do non-human identities create more audit risk than human accounts?