Should IAM teams or application teams own protection against API driven social engineering?

Where the boundary belongs, and why the answer is split

Protection against API driven social engineering is not a pure identity problem or a pure application problem. IAM teams are best placed to define the policy boundary, because they own authentication strength, actor trust, and the rules for who may initiate a sensitive action. Application teams then have to apply that boundary inside the workflow, where context, transaction type, and step-up decisions actually happen.

The practical reason for that split is that API abuse often succeeds when a request is technically authenticated but semantically inappropriate. A valid token or session is not enough if the workflow lets a caller reset recovery settings, change payout details, approve a privilege step, or trigger another high-impact action without sufficient contextual checks.

That means the control objective is not simply “block bad logins.” It is to make sure the application can distinguish a legitimate authenticated request from a socially engineered one that exploits trust in the surrounding process, especially where an attacker uses help desk paths, recovery paths, or delegated actions as the entry point.

How IAM policy and application logic divide the work

IAM should own the common policy primitives that every consumer of the API can rely on: identity proofing strength, authentication assurance, token issuance, step-up requirements, and the baseline conditions under which a subject is allowed to act. The IAM plane is also the right place to define the minimum trust needed before a workflow may be called at all.

Application teams should own the business rule that decides whether the action makes sense right now. A password reset, beneficiary change, device enrollment, or support escalation request may be authenticated, but still too risky for the current context. That judgment belongs where the transaction intent and business impact are visible.

This is why the boundary should be expressed as a policy contract, not an informal expectation. IAM can expose assurance signals, but the application must consume them and decide whether additional verification, denial, delay, or human review is required for the specific action being requested.

In practice, the cleanest operating model is to let IAM standardize who the actor is and how strongly they were verified, while the application enforces what that actor is allowed to do in this moment. That separation reduces ambiguity when teams need to explain why one request was accepted and another was blocked.

What good protection looks like in an API workflow

Good protection combines actor assurance with transaction-aware enforcement. The workflow should treat low-friction authentication as only one input, then test whether the request matches the user’s normal behavior, the sensitivity of the action, and the expected channel or device pattern. If the request looks unusual, the application should be able to require step-up or refuse the transaction.

For API driven social engineering, the strongest controls are often the ones that slow or reshape high-risk actions rather than the ones that only harden the login. That includes call-backs, out-of-band confirmation, reauthentication for sensitive steps, transaction signing, explicit approval workflows, and break-glass treatment for exceptional cases.

Because these controls depend on API consumer behavior, they should be tested end to end. If IAM sets a policy but the application ignores the signal, or if the application asks for context that IAM never provides, the protection fails at the integration point rather than at the obvious control point.

Authoritative API guidance is useful here because API abuse often appears as a design flaw rather than a perimeter failure. The OWASP API Security Top 10 is a strong reference for authorization and workflow abuse, while the NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control vocabulary for access enforcement, authentication, auditability, and configuration discipline.

Risk and Threat Considerations

API driven social engineering is dangerous because it turns legitimate access paths into abuse paths. The attacker does not always need to defeat authentication; they often need to persuade a legitimate actor, or a legitimate workflow, to approve something that should have been challenged, slowed, or verified out of band.

Failure mechanism: A valid identity assertion or session is accepted without sufficient transaction context, so the API exposes a high-impact action to a request that looks authenticated but is operationally inappropriate.

Impact: Attackers can reset recovery channels, alter account settings, approve fraudulent transfers, change trust relationships, or move laterally through support and admin workflows while staying inside normal-looking API traffic.

The strongest abuse paths tend to appear where ownership is unclear or where the control is split but not coordinated. If IAM assumes the application will handle context, and the application assumes IAM has already handled risk, the gap becomes the place where social engineering succeeds.

Practitioner Guidance

What to prioritise: Make the decision boundary explicit for every sensitive API action. IAM should set the minimum assurance requirement, but the application must own the contextual decision for the transaction itself, especially for recovery, account change, privilege, and payment-related flows.

What to verify: Confirm that sensitive actions cannot be completed on authentication alone. The workflow should be able to request step-up, reject anomalous requests, and preserve evidence showing why a request was allowed or blocked.

Common mistake: Treating IAM as the sole control owner for social engineering. That leaves applications free to accept risky transactions whenever the caller is technically valid, which is exactly where social engineering gains leverage.

Practitioner takeaway: IAM should define trust, but applications must decide transaction appropriateness; if either side cannot explain the decision in the context of a specific action, the control boundary is too weak.

Related resources from NHI Mgmt Group

• Why do public employee details make social engineering against IAM teams easier?
• How should security teams defend extended workforce onboarding and account recovery against AI-driven social engineering?
• How should security teams govern API keys used for generative AI access?
• Who should own approval policy for autonomous agent actions, IAM or application teams?