IAM handles assurance of who or what is authenticating, while application security handles whether the runtime behaviour matches a legitimate use case. Bot risk sits between those domains, so shared policy is essential. Teams should agree on which signals trigger step-up checks, where to block automation, and when to escalate suspicious sessions for investigation.
Where IAM ends and application security begins
Bot risk is shared because it has both identity and runtime dimensions. IAM is responsible for proving which actor is attempting access, binding that actor to an account, client, or credential, and deciding whether the signal is strong enough for step-up. Application security is responsible for whether the traffic pattern, workflow, and behaviour look like a legitimate user journey or automated abuse.
That split matters because a bot can authenticate “correctly” and still be malicious, or fail weak checks while still representing a legitimate automation use case. The practical question is not who owns the whole problem, but which team owns the control at each decision point: identity assurance, behavioural validation, blocking, or investigation.
Shared responsibility works best when both teams define a common bot-risk model. IAM typically owns signals such as device posture, session confidence, credential type, federation strength, and step-up outcomes. Application security typically owns signals such as request velocity, navigation anomalies, unusual API sequencing, and interaction patterns that indicate automation beyond the intended use case.
How to split signals, controls, and exception handling
The cleanest boundary is to treat IAM as the gatekeeper for who or what is authenticating, and application security as the validator of what that session is doing. If a session is high confidence at login but starts behaving unlike a real user, application security should drive the response. If a session never reaches an acceptable assurance level, IAM should own the denial or challenge.
That division also helps prevent two common failure modes. First, teams sometimes over-rely on login controls and assume good authentication makes the session trustworthy. Second, teams sometimes focus only on behaviour and ignore whether the “user” is actually a bot, a delegated process, or an abused credential. Both sides need enough context to avoid making contradictory decisions.
- IAM should define which authentication outcomes can be accepted, challenged, or denied for bot-prone journeys.
- Application security should define which runtime patterns indicate automation, scripted abuse, scraping, or account takeover.
- Both teams should agree on a single escalation path for sessions that are authenticated but suspicious in use.
For teams formalising those control boundaries, OWASP ASVS is useful because it separates authentication, session handling, and authorization checks that often sit on different operational owners.
Operating bot risk without creating ownership gaps
Bot risk becomes messy when no one owns the handoff between access control and behaviour monitoring. A workable operating model assigns joint accountability for the policy, but explicit ownership for each control. IAM owns the trust decision at entry. Application security owns the abuse decision during runtime. Security operations or fraud teams often own correlation and investigation when the signal crosses from suspicious to potentially malicious.
Good practice is to predefine the thresholds that trigger action, rather than debating each event ad hoc. That means agreeing on when to step up, when to throttle, when to block, and when to preserve evidence for review. It also means deciding which legitimate automation patterns are allowed, because overblocking trusted bots can break integrations, customer journeys, and internal workflows.
Shared policy becomes especially important when bot traffic is not obviously hostile. Some automation is intended, some is tolerated, and some is abusive but looks operationally normal. Teams should be able to explain why one session is treated as approved automation and another as risk, using the same policy language even if the technical controls differ.
Risk and Threat Considerations
Bot risk is dangerous precisely because it straddles trust boundaries. A bot may pass identity checks while still abusing application workflows at scale, or it may use a compromised credential to blend into normal sessions. The main exposure is false confidence: one team sees a valid login, while the other sees only “normal” traffic until the abuse has already spread.
Failure mechanism: Weak handoff between IAM and application security lets authenticated automation bypass one set of controls while evading the other. Attackers and abusive scrapers benefit when step-up logic, behavioural blocking, and investigation triggers are not aligned.
Impact: Unchecked bot activity can inflate fraud, enable account takeover, exhaust shared resources, distort analytics, and make incident response slower because no team owns the full signal chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Bot risk starts with who or what can authenticate. |
| V7 — Session Management | Bot risk often emerges after login in active sessions. | |
| V8 — Authorization | Bot abuse often exploits allowed actions rather than login weaknesses. | |
| Recommendation — Use V6 to separate authentication assurance from runtime abuse detection. Use V7 to constrain session reuse, fixation, and session-based abuse. Use V8 to enforce per-action checks for sensitive or high-volume workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared responsibility depends on controlling accounts and access paths used by bots. |
| Recommendation — Use CIS-5 to review and restrict accounts that can be abused by automation. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | IAM must prove the identity of human sessions that may be automated or abused. |
| IA-9 — Service Identification and Authentication | Bot traffic often uses service, workload, or application credentials. | |
| AC-6 — Least Privilege | Bot sessions become dangerous when they can do more than intended. | |
| Recommendation — Apply IA-2 to strengthen identity assurance before granting access. Apply IA-9 to authenticate non-human actors with appropriate assurance. Apply AC-6 to limit the actions available to automation and suspicious sessions. | ||
| MITRE ATT&CK | T1110 — Brute Force | Bot activity often includes credential abuse and automated login attempts. |
| T1078 — Valid Accounts | Abusive bots commonly operate with legitimate but misused credentials. | |
| Recommendation — Map repeated login failures and spray patterns to T1110 for detection. Hunt for abnormal use of valid accounts when automation is suspected. | ||
Practitioner Guidance
Decision rule: If the session is uncertain at authentication time, IAM should own step-up or denial. If the session is authenticated but the runtime pattern is abnormal, application security should own the control response. If both are true, treat it as a joint incident, not a ticket handoff.
What to verify: Make sure the policy names the exact signals each team can trigger, the action they can take, and the escalation threshold that moves the case into investigation. If a signal does not lead to a concrete decision, it is not yet a control.
Practitioner takeaway: The goal is not to force one team to own bot risk, but to ensure that authentication trust and runtime behaviour are judged together so that approved automation stays usable while suspicious sessions are stopped early.
Related resources from NHI Mgmt Group
- How do application security and IAM teams share responsibility for exposed code?
- How can IAM, HR, and security share responsibility for hire-to-access risk?
- How should security and IAM teams share responsibility for in-person identity checks?
- How do IAM and platform teams share responsibility for API security?