What should a new-hire impersonation assessment establish?
Establish who authorized the requested action, where the identity and contact details came from, and what access was actually granted. Treat a persuasive onboarding story as a claim to verify.
A person who has just joined a company may need help before their normal access works. That makes onboarding a useful scenario to examine: the support team has to help the right person without allowing an unfamiliar caller to define their own identity, contact details, and permissions.
The question for an assessment is specific: what evidence authorizes the first sensitive action? A start date, a manager’s name, or a convincing account of a broken laptop can explain why someone is asking. Your procedure must establish whether that person is entitled to the requested action.
How Octo Tempest posed as new hires
Microsoft’s October 2023 Octo Tempest report describes attackers impersonating newly hired employees while trying to induce technical administrators to reset passwords and MFA methods. Microsoft says the impersonation blended into normal onboarding processes. The observed requests concerned account recovery. Microsoft: Octo Tempest, initial access
For an assessment, name the requested action: initial credential delivery, a reset, and a new application grant create different questions.
Our UNC3944 control review examines recovery and account authority. This article focuses on an earlier question: how the support team establishes the relationship between a requester, an approved onboarding record, and a specific access decision.
Split the request into three decisions
Start with a short request such as “I start today and cannot get into the project portal.” Ask the team to separate it into three questions.
Is there an approved relationship? An employee or contractor record may establish that somebody should work with the organization. Identify who maintains that record and who can correct it. A name appearing in a ticket supplied by the requester is not independent corroboration.
Is this requester the intended person? Identify the approved verification route for someone whose usual work account is unavailable. If the route relies on a manager, establish how the team finds that manager’s contact details. Our callback contact-source guide explains why the destination matters as much as making the call.
Is this action authorized? Issuing a credential, replacing an authenticator, and adding an application permission have different effects. Record the exact requested action and its approving role. A genuine worker can still ask for access that their assignment does not justify.
NIST separates identity resolution, evidence validation, and verification that the applicant owns the evidence. Those distinctions are useful vocabulary for reviewing an onboarding process, although NIST identity proofing does not by itself establish an employment relationship or application entitlement. Choose the organization’s applicable assurance requirements rather than treating this exercise as a compliance checklist. NIST: identity proofing requirements
For each check below, the team needs an answer it can trace to an approved source. An unresolved answer means hold the sensitive action and use the named escalation route.
Onboarding review
Illustrative, not an observed result
- Approved relationship
Which record and owner establish it?
- Requester verification
Use the approved route.
- Named action authorized
Who may approve this change?
- Resulting access checked
Only if separately in scope.
Earlier success does not establish that the next step succeeded.
An expected hire still needs verification
Confirming that a worker is expected does not necessarily verify a replacement email address or the person calling. Keep the approved contact record visible when reviewing a proposed substitution. Keep the access request pending until the required verification is complete.
A deadline can require a business workaround, but it does not establish authority to bypass verification. Ask the sponsor what temporary arrangement is possible without granting the disputed access.
Leave a record the next team can use
Retain the approved engagement reference, the verification route and result, and the approver for the exact change. If access instructions were delivered, identify the approved destination and delivery evidence. Record account or permission changes separately from any tested resource access.
Refer to restricted evidence rather than copying credentials or unnecessary personal information into the handoff. The optional onboarding decision record provides these fields for a review.
Different failures need different owners
Accepting an unsupported identity claim and delivering access instructions to a caller-controlled address are different failures. If delivery remains confined to an approved destination, that restriction may stop continuation even when verification was weak. Record both findings without claiming that application access was tested.
An escalation queue nobody owns can leave a legitimate worker unable to start. Name who will take the request and when they will follow up. If verification succeeds but a requested role exceeds the engagement, refer that authorization decision to the application owner.
For a broader discussion of these handoffs, adapt the account recovery tabletop to onboarding. A tabletop establishes decisions and gaps, not credential issuance or resource access. Any technical follow-up needs its own test identity, permitted operation, stopping point, and cleanup.
