Who should own proof of work controls in an identity programme?

Why This Matters for Security Teams

Proof of work controls sit at the intersection of identity assurance, abuse prevention, and telemetry, so the ownership question is really about who can make tradeoffs without creating blind spots. If the control is treated as a narrow IAM feature, teams often optimise for access issuance while missing fraud signals, automated abuse patterns, and operational friction. If it is treated only as detection, it can become noisy and disconnected from policy.

That tension is visible across NHI programmes, where governance gaps are already common. NHIMG research shows 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, yet only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. That gap matters because proof of work controls only function when the owning team can tune thresholds, review outcomes, and respond to abuse patterns quickly.

For security teams, the practical risk is fragmentation: IAM may own the policy, fraud may own the signals, and SecOps may own the response, but none of them owns the whole control loop. Current guidance from the NIST Cybersecurity Framework 2.0 favours clear accountability across preventive and detective controls, yet many organisations still map proof of work to whichever team first encountered the issue. In practice, many security teams encounter failed tuning and unnecessary user friction only after abuse has already scaled.

How It Works in Practice

Ownership works best when one accountable team owns the policy, another owns the signal sources, and a third handles operational response, with a named decision-maker tying them together. For identity programmes, that usually means IAM or identity security owns the rule set, fraud or risk engineering owns behavioural heuristics, and SecOps owns escalation and incident handling. The key is not the job title, but whether the owner can change thresholds, approve exceptions, and measure control effectiveness end to end.

In practice, proof of work controls should be linked to the identity lifecycle rather than bolted on as an afterthought. That includes defining when a challenge is triggered, what evidence satisfies the challenge, how long the proof remains valid, and when the signal should be escalated to investigation. Where the control is protecting NHIs, the same owner should align it with secrets handling, rotation, and access review processes described in 52 NHI Breaches Analysis and the Top 10 NHI Issues research.

• Use policy ownership to define the control objective, challenge logic, and acceptable friction level.
• Use fraud or abuse telemetry to tune risk-based triggers and reduce false positives.
• Use SecOps workflows to route failed proofs into investigation or automated containment.
• Measure both bypass rates and user impact so the control remains effective and operable.

Best practice is evolving, but current guidance suggests proof of work should be governed as a cross-functional control with one accountable owner, not as an orphaned feature inside a single tool. These controls tend to break down when high-volume automation and service-to-service identity flows generate legitimate traffic that looks like abuse because the owner cannot distinguish workload patterns from attack traffic.

Common Variations and Edge Cases

Tighter proof of work controls often increase operational overhead, requiring organisations to balance abuse resistance against latency, false positives, and support burden. That tradeoff becomes more visible in customer-facing systems, developer platforms, and machine-driven workflows, where even small delays can affect adoption or reliability.

There is no universal standard for this yet. Some organisations place ownership in IAM because proof of work affects authentication journeys. Others place it in fraud or trust and safety because the control is primarily a response to suspicious behaviour. A third model, especially in higher-risk environments, gives ownership to a security engineering team that can combine identity policy, signal engineering, and escalation logic. The right answer depends on whether the dominant risk is account abuse, automated scraping, credential stuffing, or unwanted bot activity.

For NHI-heavy environments, ownership should also consider service accounts, API keys, and automation agents that cannot complete human-style challenges. In those cases, the control may need a workload-friendly alternative such as attested identity, device trust, or stronger runtime policy, rather than a literal human proof. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because it frames control selection around lifecycle and risk, not just access prompts.

Current guidance suggests assigning one owner for policy and measurement, even if several teams supply inputs. That approach avoids the common failure mode where proof of work becomes either too strict to operate or too weak to slow real abuse.

Related resources from NHI Mgmt Group

• Who should own identity-related compliance controls in practice?
• Who should own identity and device governance in a consolidated work platform?
• Who should own privileged access governance in an identity programme?
• Who should own endpoint posture in a hybrid work programme?