How should organisations tell a legitimate employee request from account takeover activity?

Why request-time verification is the real control point

account takeover is often detected too late if teams trust the login event alone. A legitimate employee can be using a valid session, but a hijacked session, consented OAuth app, or social-engineered recovery request can still drive payment, beneficiary, or access changes. The practical control is to verify the requester against an authoritative source at the moment the sensitive action is requested.

That means treating “can this person sign in?” and “should this request be completed?” as different questions. Recovery and change workflows need a stronger trust test than the normal sign-in flow because attackers often preserve the appearance of legitimacy after they have entered the account.

A good test is whether the request can be independently confirmed through a channel or record that is harder to compromise than the account itself. If the only evidence is voice, a scanned document, or answers to knowledge-based prompts, the control is weak enough to be bypassed by a determined attacker.

What legitimate request patterns look like in practice

For employee-initiated changes, the safest pattern is a step-up check that references an authoritative internal source such as HR, directory data, manager approval, or an existing privileged workflow record. The verifier should compare request context, entitlement history, device or session signals, and the business reason for the change before any high-impact action completes.

Legitimate requests usually have some combination of stable identity history and expected timing. Unusual destination account changes, urgent out-of-band recovery, new device enrollment, or a request from a freshly authenticated session should be treated as higher scrutiny, even when the person sounds familiar or can answer routine questions.

This is why strong identity risk management and detect-and-protect controls matter together: one establishes who is asking, the other helps decide whether the request is consistent with normal access behaviour. A request can be technically authenticated and still be fraudulent in context.

How to separate takeover signals from ordinary employee activity

The clearest distinction is not whether the request sounds plausible, but whether it fits the known identity and access pattern for that employee. Takeover activity often shows one or more of these signs: a reset followed immediately by a sensitive change, a request from an unfamiliar device or location, rushed beneficiary edits, or repeated attempts after failed verification.

Legitimate requests usually tolerate verification friction; attacker-driven requests usually do not. That is useful because the fraudster needs speed, while the real employee can generally wait for stronger confirmation. The more irreversible the action, the more the organisation should prefer a verified workflow over a conversational one.

For broader attack path awareness, MITRE ATT&CK Enterprise Matrix is a useful reference for understanding credential access, privilege escalation, and post-compromise actions, while NIST AI Risk Management Framework can help teams think about assurance and human oversight where automated decisioning is involved.

Risk and Threat Considerations

Account takeover is dangerous here because the attacker does not need to defeat every control, only the one control that authorises the business change. Recovery, payment, and beneficiary workflows are especially attractive because they convert access into durable financial or operational impact.

Failure mechanism: Weak request-time checks allow a hijacked account, a fraudulent caller, or a coerced help-desk interaction to be treated as legitimate, especially when the process overweights voice, documents, or static knowledge questions.

Impact: Attackers can redirect funds, alter beneficiary details, persist inside the account, or use the trusted workflow to normalise future abuse, making the compromise harder to unwind than the initial login event.

Practitioner Guidance

What to verify: Verify the request against an authoritative source that is harder to spoof than the account session itself. The best check is one that can be independently confirmed from a trusted record or a separate approval path, not just from the same channel the attacker already controls.

Decision rule: If the request can change money movement, recovery authority, or identity-linked destination details, require stronger verification than the sign-in step and delay completion until the check is passed. If the request is low impact, a lighter control may be acceptable, but only if the same path cannot later be reused for a higher-value change.

Common mistake: Treating “realistic voice” or “matches the uploaded document” as sufficient proof. Those signals can support review, but they should not be the final control for high-impact changes when takeover risk is on the table.

Practitioner takeaway: The safest organisations do not ask “does this person sound like the employee?”, they ask “can this request be verified from a source the attacker is less likely to control than the account itself?”

Related resources from NHI Mgmt Group

• How can organisations tell legitimate automation from compromised service account activity?
• How can retailers tell legitimate holiday shoppers from account takeover activity?
• Why does account takeover create risk even when the account activity looks legitimate?
• How should organisations use biometric passkey binding to reduce account takeover risk without making authentication harder for legitimate users?