Who is accountable when a fake worker gains access and causes damage?

Why This Matters for Security Teams

A fake worker can only cause damage after a control gap lets a fraudulent identity be trusted, provisioned, and later over-privileged. That makes accountability more than a human resources question. It becomes a control ownership question tied to identity proofing, access issuance, and ongoing monitoring. NHI Management Group has repeatedly shown how identity abuse escalates once credentials or trust decisions are accepted without strong evidence, including the patterns documented in the 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10.

The practical issue is that many organisations still split responsibility across HR, security, IAM, procurement, and the hiring manager without naming a single approver for identity assurance. When a fake worker gains access, each group can point to another step in the workflow. That is exactly why security teams need auditable proof that the person or entity was verified before the account was activated, not after the incident. In practice, many security teams encounter this failure only after the account has already been used to access systems or exfiltrate data, rather than through intentional control testing.

How It Works in Practice

Accountability should follow the control that failed, not just the person who made the final click. If the issue is fraudulent onboarding, the accountable owner is usually the team that approved identity assurance and access issuance without sufficient evidence. If the issue is stale access after a role change, the accountable owner may shift to IAM or the system owner. Current guidance suggests treating this as a chain of custody problem: who validated the identity, who authorised access, who provisioned it, and who failed to revoke or review it.

In mature programs, that chain is enforced through policy, workflow, and logging. Useful controls include:

• Identity proofing with recorded evidence before activation.
• Named approvers for each access request, not generic group approval.
• Role-based access reviews with documented exceptions and expiry dates.
• Centralised logging so the security team can reconstruct who approved what, and when.

For workforce identity, this often intersects with Ultimate Guide to NHIs because the same governance pattern applies whether the subject is a contractor, service account, or agentic workload: the identity must be proven, the access must be justified, and the owner must be named. On the standards side, the OWASP Non-Human Identity Top 10 and NIST identity guidance both reinforce that access decisions need traceable evidence, not informal trust.

The most operationally sound model is to assign primary accountability to the control owner for identity proofing and secondary accountability to the business approver who vouched for the worker’s legitimacy. These controls tend to break down when onboarding is outsourced, evidence is stored in disconnected HR and IAM systems, and access is granted before verification is complete because the audit trail becomes too fragmented to prove where the failure occurred.

Common Variations and Edge Cases

Tighter identity assurance often increases onboarding friction, so organisations have to balance faster hiring against stronger proofing and review. That tradeoff becomes more visible when contractors, vendors, and geographically distributed workers are involved, because the evidence standard may differ by jurisdiction and employment model.

There is no universal standard for this yet, but current guidance suggests treating higher-risk access as a separate approval path with stronger evidence and shorter review windows. In low-risk cases, the hiring manager may be the practical business owner. In high-risk cases, security or IAM may become the accountable control owner because they configured the trust boundary and access policy. If a fake worker is actually a compromise of an upstream HR or identity provider, accountability can extend to the integration owner as well.

One useful way to reduce ambiguity is to map ownership to the specific failure point rather than the incident outcome. That approach aligns with lessons from the DeepSeek breach, where identity, exposure, and access governance failures can compound quickly once trust is misplaced. It also helps when the same individual holds multiple roles, because a single named approver is easier to audit than a committee with no clear escalation path. The weak spot is hybrid environments with shared service desks and delegated administration, where fragmented approvals make accountability hard to prove after the fact.

Related resources from NHI Mgmt Group

• Who should be accountable when a fraudulent hire gains internal access?
• Who is accountable when a DDoS outage disrupts customer access?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who should be accountable for DNS access reviews?