IAM should own the access policy, identity signals and entitlement rules, while fraud teams should own abuse patterns, enforcement tuning and operational triage. If one team owns all of it, the organisation usually gets either weak enforcement or an overzealous customer experience. Shared governance is the right model.
Who should own which part of account sharing controls?
account sharing is really two problems at once: policy and entitlement design on one side, and abuse detection and enforcement on the other. IAM is best positioned to define what is allowed, how identity and entitlement rules are expressed, and which signals qualify for access. Fraud is best positioned to interpret suspicious sharing patterns and decide when to tune or escalate enforcement.
The split matters because the control fails when it is designed as either a pure identity policy or a pure fraud rule. If IAM owns only the policy without operational signals, the rules tend to be easy to bypass or impossible to maintain. If fraud owns everything, the organisation often gets reactive enforcement without durable access standards.
Shared governance works best when each team owns the part it can sustain: IAM sets the guardrails, fraud validates the abuse model, and both agree on exception handling and customer impact thresholds.
Where the boundary should sit in practice
A clean operating model starts with the question of what must be true before an account can be shared at all. That is an access-policy decision, so IAM should own the identity signals, entitlement rules, allowed-use criteria, and the lifecycle of the control itself. This includes how the organisation defines a shared account, when sharing is prohibited, and what evidence is required for an exception.
Fraud should not be asked to define the access model, because fraud signals are usually probabilistic and context-heavy. Their value is in recognising abuse patterns such as unusual device switching, velocity spikes, geographically implausible usage, repeated challenge failures, or account takeover behaviour that looks like sharing. Those patterns are essential inputs, but they should tune the control, not replace the policy.
In other words, IAM owns the structure of the rule, while fraud owns the behavioural interpretation of when the rule is being gamed. That separation keeps policy durable without making enforcement blind to real abuse.
Why shared governance is the right operating model
Account sharing touches both legitimate customer experience and adversarial misuse, so no single team sees the whole picture. IAM generally optimises for consistency, entitlement accuracy, and auditability. Fraud optimises for abuse containment, false-positive control, and triage speed. A Identity Security Programme Guide is a useful way to think about that operating model: the control needs a shared RACI, not a single owner that tries to absorb both policy and behavioural enforcement.
The practical benefit of shared governance is that the teams can separate “what should be allowed” from “what looks unsafe in the wild.” That prevents a common failure mode where identity teams harden the policy until customer friction becomes unworkable, or fraud teams over-tune detection until the rule is too weak to matter. The right model is a control with one policy owner, one abuse owner, and one joint decision path for exceptions and escalation.
For organisations managing shared or reused credentials at scale, the same principle shows up in lifecycle control. The NHI Lifecycle Management Guide and the lifecycle processes for managing NHIs both reinforce the point that access rules only stay effective when ownership, review, and enforcement are clearly defined over time.
What good looks like when the control is working
Good practice is not “IAM does policy and fraud does everything else.” It is a control where policy, signals, and escalation criteria are explicitly connected. IAM should be able to explain which account-sharing cases are allowed, which are disallowed, and which are exceptional. Fraud should be able to show which behavioural signals trigger step-up review, throttling, or enforcement action.
One useful test is whether either team can change the control without breaking the other team’s job. If IAM can update entitlement logic without fraud involvement, abuse controls may lag reality. If fraud can tighten enforcement without identity governance review, legitimate users may be blocked in ways the access model never intended. A Identity Fraud Prevention Guide is relevant here because it reflects the need to combine behaviour signals with a governed access model rather than treating them as interchangeable.
That same discipline is reflected in broader fraud and access governance guidance from CSA Cloud Controls Matrix, especially where IAM-style controls must be paired with monitoring, accountability, and exception handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Account sharing controls depend on lifecycle and management of authenticators. |
| AC-6 — Least Privilege | Shared-account decisions should enforce minimal access and limited entitlement scope. | |
| Recommendation — Define ownership for credential lifecycle, rotation and reuse restrictions. Limit shared access to the smallest necessary privileges and review exceptions regularly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account sharing is fundamentally an account management and ownership control problem. |
| Recommendation — Assign clear account ownership, review sharing exceptions and remove unnecessary shared access. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governance maps directly to who owns access rules versus abuse enforcement. |
| Recommendation — Separate access-policy ownership from monitoring and enforcement responsibilities. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared accounts often accumulate excess privilege, increasing abuse impact if misused. |
| Recommendation — Right-size shared access and remove privileges that are not explicitly needed. | ||
Practitioner Guidance
What to prioritise: Define a single policy owner in IAM and a single operational owner in fraud before tuning any detection logic. Without that split, every exception becomes a negotiation and every alert becomes a policy debate.
What to verify: Check that the sharing policy can be described in rules, not just intent. The team should be able to show who is allowed to share, which identity signals are trusted, how exceptions are approved, and which fraud signals change enforcement.
Common mistake: Do not let fraud become the de facto policy team or let IAM own enforcement thresholds it cannot observe. The first creates brittle customer friction, the second creates controls that look strong on paper and weak in operation.
Practitioner takeaway: The healthiest model is policy ownership in IAM, abuse ownership in fraud, and a shared escalation path for edge cases, because account sharing controls fail when governance and behavioural enforcement are collapsed into one function.