Secure onboarding: a new hire's first 30 days

The conclusion: a new hire does not know the protocols yet, but already has access and something to prove

New hires should be tested within their first thirty days, and the first step is not the induction talk: it is making sure their account falls under the same behavior measurement as everyone else from the day it is created, not in the next quarterly cycle. Everything else arranges itself around that decision.

The minimum calendar fits into three moments. Day one, access plus a verification protocol: who to ask when something feels off, and through which channel. Week one, context instead of theory: what a pretext looks like when it targets someone who does not yet know the faces or the email signatures at their own company. Month one, the first real test of behavior under a simulated attack, with immediate training if they fail. The underlying logic is simple: a person's window of greatest vulnerability is also the window in which almost nobody is measuring them.

Why attackers prefer someone who has been there two weeks

Someone who just joined meets every condition a deception needs. They have access to corporate email, to the systems their team uses, and often to spending tools or customer data, because provisioning is done quickly so they can start working. At the same time, they lack the judgment that only time provides: they do not know how their director writes, cannot tell an odd request from a house habit, and do not recognize the tone of the ten people who might message them with urgency.

On top of that sits an incentive nobody states out loud but everyone recognizes: someone two weeks in wants to prove they deliver. Asking "is this legitimate?" carries a higher perceived social cost for them than for someone with three years at the company. That silent calculation, made in seconds in front of an email demanding immediate action, is what the attacker is buying.

It is worth remembering how the attempt arrives. CISA notes that more than 90 percent of successful cyberattacks begin with a phishing email, so the ground where a new hire's first test plays out is exactly the inbox they were just handed. And Cisco's 90-5-5 framework, which estimates that around 90 percent of breaches involve a human factor, explains why flawless technical provisioning does not close the gap: the door opens through a person's behavior, not through a missing control.

The three pretexts that work on a new hire: authority, urgency and the will to help

The first is authority. An email signed by a director the person has never met, asking for one specific thing in a cordial but firm tone, has nothing to be checked against. A long-tenured employee knows that director never asks for anything by email; the new hire has no such memory and simply sees a title above their own.

The second is urgency. The classic pretext arrives wrapped in a deadline, and it works because a newcomer reads delay as a bad first impression. It is not carelessness, it is arithmetic: they would rather be wrong for acting than wrong for waiting. In business email compromise (BEC), where someone impersonates an executive or a supplier to redirect a payment or a piece of data, that time pressure is the engine of the entire deception.

The third, and the most uncomfortable, is the will to help. It is the very disposition the company rewarded when it hired them, turned against them. The pretext does not corner the person, it offers them a chance to solve something fast: an HR request about their own contract, a supposed IT colleague who needs to confirm an access, a client demanding a file. None of these three pretexts requires sophisticated technology. All they require is that the person still has nothing to compare against.

What should happen on day one, in week one and in month one

Day one, two concrete things. First, the account enters the behavior measurement program the moment it is created, in the same flow that assigns email and access, not on a separate list someone processes later. Second, a one-sentence verification protocol the person can repeat from memory: any request for money, credentials or data gets confirmed through a channel different from the one it arrived on, and there is never a penalty for asking. That second part matters as much as the first, because a new hire's silence is almost always fear of being a nuisance, not ignorance.

Week one, context rather than curriculum. Who can ask them for a payment and what that request actually looks like. Which tools the company uses (and therefore which it does not, which turns any notification from an unfamiliar platform into a signal). How to report something suspicious, with the exact channel, not the abstract instruction to report. None of this needs to take an hour.

Month one, the test. A realistic simulation aimed at their role and their company's real context, plus specific training the moment they fail, if they fail. Correction delivered immediately on one's own mistake is what leaves a mark, and it is the same reason a training program built on completion rather than behavior tends to disappoint, as we covered in why your security training program is not working. Then, weeks later, test them again with a different template from the same category, which is the only honest way to know whether they learned the lesson or just remembered one email.

The mistake of leaving the first simulation for next quarter

A program running on a quarterly calendar produces an absurd situation almost everyone lives with: the most exposed person in the company is the only one nobody is measuring. Someone who joined in the second week of the quarter can spend more than two months with full access and zero signal about their behavior, precisely during the period when their defenses are weakest. By the time the general campaign finally arrives, they are no longer a new hire: they are someone who has spent a quarter making decisions without a net.

The cost is not only the risk left open during those two months. It is also that the one baseline worth having is lost. Measuring a person in their first week shows how they behave before the company's culture shapes them; measuring them a quarter later mixes their own judgment with what they absorbed by osmosis, and it becomes impossible to tell which is which. The alternative is not more simulation volume for everyone. It is making the trigger the event (a person joined) instead of the date (the quarter came around).

Offboarding: the credential that stays alive after the person is gone

The lifecycle closes where it is usually neglected. When someone leaves, the primary account almost always gets disabled, but the credential does not live only there: it lives in the third-party services where that person signed up with their corporate email, in active sessions that do not expire when the user is deactivated, and in the passwords they reused, which will surface in the next breach of some service that has nothing to do with the company. The account gets closed; the email and password pair keeps circulating.

The speed at which that gets exploited is the argument for not leaving it on a to-do list. Mandiant M-Trends 2026, based on more than 500,000 hours of incident investigation in 2025, documents that the handoff time between initial access and the secondary actor executing the attack collapsed from more than 8 hours in 2022 to 22 seconds in 2025.

A credential that surfaces in a leak today is not a risk that ripens over weeks. That is why continuous credential exposure monitoring is not an exit task: it is a layer that runs permanently and keeps raising alerts after the person is off the payroll. It is also the first block of any serious rollout, as we laid out in how to build a human risk program in 90 days.

Fensivo applies this logic across the full employee lifecycle. It continuously monitors whether credentials show up in breaches and triggers action with a deadline, sends phishing simulations personalized by role and by the company's real context, delivers microlearning within minutes when someone falls, and validates with a retest weeks later that behavior actually changed. This is human risk management (HRM) for companies with 25 to 500 employees, up and running via OAuth in a day. You can see how it applies to each case in use cases.

If the person who joined last week received an email today from your CFO asking for an urgent transfer, would you know what they would do, or would you have to wait until next quarter to find out?