Manipulating a trusted workflow
Social engineering uses deception, impersonation, urgency, authority, reciprocity, fear, helpfulness, or routine to make a person or process perform an action that benefits an attacker. The target can be a user, help desk, administrator, developer, vendor, executive, or customer.
The attack often uses valid interfaces. It asks support to reset an authenticator, a user to approve a prompt, finance to change payment data, or an administrator to add a federation trust.
Information and pretext
Attackers collect names, roles, vendors, travel, relationships, procedures, identifiers, and internal language. They create a pretext that fits the target's job and can span email, telephone, chat, video, ticket, and in-person contact. One interaction can learn the control; later interactions can exploit it.
Do not rely on private biographical facts as identity proof. A caller can obtain or infer them, and a compromised insider can know them legitimately.
System controls
Use phishing-resistant authentication, named-resource approvals, independent verification through a known channel, dual control for high-impact changes, narrow support authority, delay and notification for recovery, transaction limits, and fast reporting and containment. Make the secure verification path available under time pressure.
Bind a support or approval action to the exact account, authenticator, resource, change, destination, and lifetime. Do not let a persuasive story replace required evidence.
Failure and residual risk
Training cannot make a bearer secret origin-bound or stop a help desk that can bypass all factors. A callback fails if contact data came from the attacker or the same compromised account. Deepfake audio or video can weaken informal recognition. Excessive friction can cause staff to create unofficial exceptions.
A real colleague can be coerced, compromised, mistaken, or malicious. Verification must establish the action and authority, not only the apparent person.
Pomerium boundary
Pomerium can authenticate access to support and administration tools and apply route policy. It does not verify the truth of a caller's story or constrain application actions unless they are represented in policy. Identity providers and application owners must protect enrollment, recovery, authenticator changes, federation, and high-impact transactions.
Evaluation checklist
- Which person or process can change identity, recovery, policy, payment, trust, or credential state?
- What public, breached, internal, or previously elicited facts make the attacker's pretext credible?
- Does verification use a known independent channel and bind to the exact requested action?
- Can urgency, executive authority, support empathy, or an unavailable normal path create an exception?
- How quickly can the target report the event and revoke every action already taken?
