Who should own fake-hire risk once credentials are issued?

When fake-hire risk becomes an identity governance problem

The ownership question changes at the point credentials are issued. Before that, HR may lead fraud screening, but once an account exists the organisation has created an access path that can be abused, delegated, or left open after onboarding fails. That shifts the issue into shared identity governance, where IAM, security, and HR each hold part of the control and revocation chain.

That is why the accountable owner cannot be a single function acting alone. HR may validate the person; IAM must control issuance, assurance, and lifecycle state; security must treat suspicious identity creation as an exposure that can become an incident. In practice, the owner is the function that can prove who approved access, who can revoke it, and who is responsible when the account is not legitimate.

When ownership is vague, fake-hire risk turns into a gap between screening and control enforcement. A candidate can pass hiring checks yet still receive credentials, role assignments, or downstream access that no one is actively monitoring. The correct governance model is the one that makes ownership explicit before access is granted and preserves it through joiner, mover, and leaver events, not just at the interview stage.

Where the control boundary should sit

Once identity creation is in play, the control boundary belongs with the team that can enforce revocation and least privilege. That usually means IAM owns identity proofing, account lifecycle, and access removal, while security sets the risk threshold and monitors for anomalous behaviour. HR remains essential, but it is no longer the sole control point because the harm now comes from misuse of active access, not only from hiring deception.

This also means the ownership model should be documented as a lifecycle decision, not an HR exception process. If a record cannot show who approved the account, what evidence supported issuance, and what conditions would trigger immediate disablement, the organisation has no reliable way to separate legitimate onboarding from fraudulent access creation. Shared ownership works only when the handoffs are explicit.

API key lifecycle discipline is a useful analogue here: issuance, scoping, expiry, and revocation are the controls that matter once something can authenticate and act. The same logic applies to workforce accounts, even though the actor is human rather than a secret.

What good ownership looks like in practice

Good ownership is not a committee with no action rights. It is a named operating model in which HR flags the hiring decision, IAM owns identity lifecycle controls, and security owns escalation when the identity appears synthetic, duplicated, or inconsistent with the onboarding record. The account should not be created until the approver chain, identity evidence, and access scope are all clear.

This is where identity governance needs to include revocation authority from the start. If a fake-hire signal emerges after credentials are issued, the response must be immediate disablement, not a long investigation while access remains live. The practical test is simple: can the organisation prove who can shut the account down, and can that happen without delay across all connected systems?

For teams that manage both people and machine access, the same lifecycle thinking appears in credential rotation challenges and in the secrets management guide, because both are really questions of ownership, expiry, and emergency removal. The difference is that workforce fraud adds HR validation to the mix, but it does not remove the need for technical control.

Risk and Threat Considerations

Fake-hire scenarios become materially worse after credentials are issued because the attacker, or fraudulent employee, now has a normal-looking access path inside the environment. That can turn a hiring fraud into account abuse, data exposure, internal reconnaissance, or lateral movement before the organisation realises the person should not have had access at all.

Failure mechanism: Ownership stays with HR after access creation, so no control owner is actively responsible for credential revocation, access scoping, or anomaly review. The account remains valid long enough for misuse to look like ordinary employee activity.

Impact: The organisation absorbs a preventable access-risk event, including exposed data, unauthorised actions, delayed containment, and unclear accountability for shutdown and remediation.

Practitioner Guidance

What to prioritise: Assign a single accountable owner for the access lifecycle, with HR as input and IAM or security as the control owner once credentials exist. If nobody can disable the account quickly, ownership is not yet real.

What to verify: Confirm that onboarding approval, identity evidence, access issuance, and revocation authority are all recorded and testable. The strongest signal is whether the organisation can remove access immediately without waiting for a manual HR decision.

Common mistake: Treating fake-hire risk as a hiring-screening problem only. Once the account is live, the governance question becomes whether the organisation can detect and cut off illegitimate access before it behaves like a normal insider.

Practitioner takeaway: The right owner is the team that can govern the account after it exists, not the team that only judged the person before issuance.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?