How should security and fraud teams redesign their operating model when account takeover becomes a shared risk?

Redesign the operating model around a shared identity-risk problem

When account takeover is treated as a shared risk, the operating model has to move from function-specific triage to a common operating picture. That means security and fraud teams should classify events with the same risk logic, use the same entity and session data, and agree on when an event is a customer abuse issue, an identity compromise, or both. The goal is not organisational neatness, it is faster and more accurate containment.

Shared risk handling works best when teams stop optimising only for their own loss or alert queues. A fraud analyst may see monetisation behaviour first, while a security analyst may see authentication abuse or anomalous access first; both views matter. The operating model should therefore preserve each team’s specialist judgment, but route it into a single decision path for correlation, escalation, and customer impact assessment.

One practical signal of why this matters is the scale of non-human and credential-driven compromise in real environments. NHIMG research notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which reinforces a broader operating lesson: attack paths often span systems, users, and automation, so narrow team boundaries miss part of the picture.

For teams building this model, the first design choice is ownership of the common taxonomy. If security and fraud use different definitions for compromise, suspicious login, session abuse, or recovery confidence, they will continue to duplicate work and disagree on severity. A shared operating model should define the event classes, the handoff thresholds, and the evidence required before a case can move from detection to response.

Build one detection-and-response loop instead of two parallel queues

The most effective redesign is usually a joint queue or federated workflow with shared enrichment, not a merger of the teams. Security should still own identity telemetry, authentication controls, and compromise indicators, while fraud should still own behavioural monetisation patterns, payment abuse, and account misuse. What changes is that both teams work from the same case object, with the same timeline of signals and the same escalation criteria.

That shared loop should include common enrichment fields, device and session history, IP and geolocation context, recent password or MFA changes, recovery events, beneficiary changes, and any linked accounts or platforms. When the same case is visible across the user journey, teams can distinguish a noisy login anomaly from a full account-takeover chain. It also reduces the common failure mode where one team closes an alert while the other team is still seeing the attack unfold.

Shared logic also improves consistency in response. For example, a fraud containment action such as step-up verification or payment blocking should be aligned with security actions such as token invalidation, credential reset, or session revocation. When those actions are not coordinated, defenders can inadvertently create a recovery gap that the attacker uses to regain access.

Useful operating-model changes are usually structural rather than tactical: shared severity tiers, a single incident review cadence, a common analyst playbook, and a clear rule for who leads when both customer loss and identity compromise are present. The right measure is not team efficiency in isolation, but time to coordinated containment across the combined case.

Practitioner Guidance

What to verify: Confirm that both teams are looking at the same source-of-truth data for user, session, device, and recovery activity. If one team cannot see the evidence the other team uses to justify containment, the operating model is still fragmented even if the org chart looks integrated.

Decision rule: If an event can lead to both unauthorised access and financial loss, treat it as a joint case by default and let specialist ownership be assigned inside the workflow, not before it. That prevents premature closure under one function’s success criteria while the other function still carries unresolved risk.

What practitioners underestimate: The hardest part is usually not detection quality, but disagreement over case ownership after the first alert fires. Teams need an explicit rule for escalation, evidence preservation, and customer communication so they do not lose time negotiating responsibility during an active compromise.

Practitioner takeaway: The operating model should make account takeover look like one attack path with multiple business impacts, because coordinated containment is faster and more reliable than two separate teams solving two partial versions of the same incident.

Related resources from NHI Mgmt Group

• How should security teams refine identity verification flows for carsharing platforms to reduce fraud and account takeover risk?
• How should security teams use browser controls to reduce account takeover risk?
• How should security teams reduce fraud risk in account recovery workflows?
• How should security teams reduce help desk account takeover risk?