Security teams should combine identity proofing, hiring record validation and manager attestation before granting production access. The point is not to add friction everywhere, but to make sure the person, the employment record and the access request are aligned before credentials are issued.
What “legitimate” should mean before access is provisioned
Before a new hire gets access, security teams should treat “legitimate” as a three-part check: the person is who they claim to be, the employment relationship is real, and the requested access matches an approved role or manager request. That keeps provisioning tied to an authenticated business need rather than to a name in a ticket.
Identity proofing matters because the main failure is not a bad password, it is onboarding the wrong person or the right person with the wrong authority. The verification standard should be high enough for the access being granted, with stronger checks for production, privileged, or sensitive systems than for low-risk internal tools.
For background on lifecycle controls and access governance, see the Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics.
How to validate the employment record and request path
Security teams should not rely on a single onboarding form. The practical control is to cross-check the HR record, the start date, the manager relationship, the job family, and the system owner’s approval before any credential is issued. If any one of those pieces is missing or inconsistent, the request should pause until the discrepancy is resolved.
Manager attestation is useful because it confirms that someone with business accountability expects the hire to receive access. The access request should also reflect the minimum initial entitlement set for the role, not an aspirational access package that assumes future need.
Where lifecycle discipline is the main control path, the IAM and IGA Basics guide and the Joiner-Mover-Leaver (JML) Guide both reinforce the need for authoritative-source provisioning.
What good looks like in a secure onboarding workflow
A sound workflow uses authoritative data, clear approval boundaries, and time-bounded provisioning. The HR system or equivalent source of record establishes the employment event, the manager confirms the need, and security verifies that the identity evidence meets the risk level of the target systems before access is granted.
Good practice is to create the account only after the verification steps are complete, then assign the smallest useful access set, and review any high-risk access separately rather than folding it into default onboarding. That prevents “birthright” access from silently expanding into production access without a second look.
For lifecycle-specific guidance, the NHI Lifecycle Management Guide is useful because it frames provisioning as part of an explicit lifecycle, not a one-time setup task.
Risk and Threat Considerations
If legitimate-hire checks are weak, the main risk is unauthorized access through a valid onboarding path. That can happen when fake employment records, spoofed manager approvals, or copied identity documents are accepted without reconciliation against a trusted source of record.
Failure mechanism: A provisioning team trusts one control signal, such as a ticket or email, while skipping cross-checks against HR and manager authority, so access is issued to the wrong person or at the wrong privilege level.
Impact: The result can be account misuse, overprovisioning, delayed detection of insider abuse, and a larger blast radius if the new account lands in production with broad entitlements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | New-hire access starts with authenticating the person receiving credentials. |
| IA-12 — Identity Proofing | The question is specifically about proving a new hire is legitimate before access. | |
| AC-2 — Account Management | Provisioning and approval of new accounts are the core control actions here. | |
| Recommendation — Require verified user identity before issuing any organizational account. Use identity proofing before creating accounts for new hires. Link account creation to documented approvals and role-based need. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity proofing and joiner provisioning are identity-management activities. |
| A.5.18 — Access rights | The answer concerns when access rights may be granted to a new hire. | |
| Recommendation — Define authoritative identity records before granting access. Grant access rights only after legitimacy checks are complete. | ||
Practitioner Guidance
What to prioritise: Treat identity proofing, employment validation, and approval validation as three separate checks, not one combined onboarding step. If the hire will touch production, require a stronger proofing path and a more explicit approval trail than you would for ordinary internal access.
What to verify: Confirm that the legal or HR record, manager attestation, job role, and requested system access all line up before issuance. If the request is inconsistent with the role, hold the ticket rather than “fixing it later” after the account exists.
Common mistake: Teams often assume that a finished HR record is enough to prove access legitimacy. It is not, because the security decision is about whether the person should receive a specific set of permissions now, not whether they appear on payroll.
Practitioner takeaway: The safest onboarding control is to make access contingent on reconciled evidence from separate authorities, because legitimacy is demonstrated by agreement between identity, employment, and approval, not by any one field alone.
Related resources from NHI Mgmt Group
- What should security teams do before sharing browser-based simulator access?
- How should security teams handle guest access before enabling GenAI?
- What should security teams verify before using OIDC for AI agents?
- What should teams verify before trusting access intelligence in frontline environments?