How can organisations verify identity when the request itself may be malicious?

Why malicious requests are a verification problem, not just an authentication problem

When a request may itself be adversarial, the core challenge is that the message is untrusted even if the sender looks legitimate. Verification has to answer two separate questions: who is asking, and whether this specific action is appropriate right now. That is why identity proof alone is insufficient for resets, privilege changes, payout changes, or other high-impact requests.

In practice, the safest pattern is to treat the request channel as potentially compromised and move verification to a separate, harder-to-spoof path. That can mean callback confirmation, signed approvals, device-bound reauthentication, or a second channel with an independently known contact route. The important point is that the verification step must be harder to fake than the original request.

For sensitive actions, verification should also be tied to the action itself. A request to change a password is not the same as a request to change an email address, and neither should be validated with a generic approval. The more the action changes access, authority, or recovery paths, the more the organisation should require explicit, action-specific confirmation before it proceeds.

Which controls make malicious-request verification reliable?

Reliable verification usually combines stronger authentication, narrow approval authority, and pre-established escalation rules. If a request can trigger access restoration or privilege change, the approver should not be the same person who benefits from the change unless the process adds independent review. That separation reduces the chance that a convincing request becomes an easy way to bypass controls.

Scope matters as much as strength. A well-designed process limits who can approve what, under what conditions, and with what evidence. For example, reset authority should be tightly constrained, and any exception should leave a clear audit trail. Active Directory and Entra ID Hardening Guide and Identity Security Programme Guide are useful if your verification process depends on strong admin boundaries, delegated approval, and clear ownership.

Verification also works better when the organisation has pre-registered trustworthy reference points. That includes known callback numbers, out-of-band channels, manager relationships, device trust signals, and step-up requirements for sensitive changes. In mature environments, the verification method is chosen based on the impact of the request, not on convenience for the requester.

How to prevent a trusted channel from becoming the attacker’s shortcut

The biggest operational mistake is assuming that a familiar channel is a safe channel. Email, chat, ticketing, and even voice can all be abused if the attacker can impersonate the requester or manipulate the conversation. Verification should therefore be designed around the possibility that the request path has already been compromised.

That means organisations should avoid granting resets or privilege changes on the basis of urgency, familiarity, or repetition alone. The more irreversible the action, the more the process should demand independent evidence and a separate approval route. NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-207 Zero Trust Architecture both reinforce the idea that trust should be verified continuously and at the point of action, not assumed from the channel alone.

Where the request affects sensitive systems or access paths, organisations should also pay attention to the blast radius of a false approval. A single mistaken reset can become a full account takeover; a single mistaken privilege grant can create persistent abuse. Verification is therefore not only an identity task, it is a containment control.

Risk and Threat Considerations

Malicious requests are attractive because they let an attacker use legitimate business process against the organisation. Instead of breaking the system directly, the attacker tries to persuade staff or automation to perform the change for them, which can bypass technical controls that would otherwise block direct access.

Failure mechanism: The verification workflow trusts the request channel, the apparent requester, or the urgency of the request more than independent evidence. That creates an opening for impersonation, social engineering, or compromised-account abuse to drive resets, approvals, or privilege escalation.

Impact: A successful fake request can lead to account takeover, unauthorized access, privilege expansion, fraud, or persistent control of recovery paths. In access-heavy environments, a single bad approval can create a broader compromise than the original malicious message ever could.

Practitioner Guidance

What to verify: Verify the request through a channel that is independent of the original message and anchored to pre-established contact or trust data. For high-impact actions, require a separate confirmation step that is specific to the exact change being requested.

Decision rule: If the request changes authentication, recovery, or privilege, treat it as a high-risk action even when the requester sounds credible. If the request is routine but cannot be independently validated, default to delay and callback rather than exception handling.

Practitioner takeaway: The right test is not whether the requester appears authentic, but whether the organisation can prove the request is legitimate without relying on the same path the attacker may already control.

Related resources from NHI Mgmt Group

• Why do organisations need to verify identity at every access request for high-risk digital services?
• How should organisations verify a critical identity verification provider?
• How should organisations verify identity documents without creating too much friction?
• What should organisations verify before relying on self-service identity features?