Overview
Zero Trust architectures are built around a straightforward principle: never assume trust and continually verify access. Organisations increasingly apply this through conditional access, phishing-resistant MFA, device compliance, least privilege and continuous identity monitoring. However, there is a difficult point before many of those controls can operate effectively: the moment a new identity is created. A new employee may not yet have a registered device, passkey, authenticator or established behavioural history. Someone within HR, IT or the service desk must first decide that the person requesting access is genuinely the individual the organisation intends to trust. If that initial identity decision is wrong, every security control that follows may simply protect the attacker’s newly created account.
When Zero Trust Starts With Human Trust
Established employees can usually be verified through several existing signals. They may have a known device, previous authentication activity, registered MFA methods, corporate credentials and a history of interaction with the organisation. New employees do not have that history. The organisation therefore needs to bootstrap trust from identity documents, interviews, employment records and onboarding processes. This creates a security window where manual verification can carry significantly more authority than it appears to. An attacker who successfully impersonates a new employee does not necessarily need to steal credentials later. The organisation may create legitimate credentials for them.
Strong MFA Cannot Correct a False Identity
Once onboarding is complete, the new employee may be issued a corporate device, Microsoft Entra ID account, VPN access, SaaS permissions and phishing-resistant MFA. From a technical perspective, everything may appear secure. But if the person behind that identity was never legitimate, the organisation has simply created a strongly authenticated attacker. This is why MFA enrolment deserves particular attention. The first authentication method registered against an account becomes the foundation for future verification, password resets and account recovery. The process establishing that first trusted factor therefore needs protection comparable to the authentication controls that depend on it later.
Identity Proofing Must Become Part of Zero Trust
A mature identity architecture should treat identity creation, authentication and authorisation as connected but separate security stages. Remote-worker onboarding may require stronger identity validation, controlled device provisioning and independent verification before credentials or authentication methods are issued. High-impact actions such as MFA registration, password recovery and privileged-access activation should also have stronger verification paths rather than relying solely on service-desk judgement. Continuous verification remains equally important after onboarding. Unexpected geographic activity, changes to payment details, unusual authentication-method registrations, remote-access tools or inconsistent device behaviour may reveal that the identity originally established no longer represents the person the organisation believes it does.
Expert in the Cloud Insight
Zero Trust is often described as “never trust, always verify.”
But there is a more fundamental question that comes first:
What evidence created the identity being verified?
Firewalls, MFA, conditional access and privileged-access controls can determine whether a recognised identity should reach a resource. They cannot independently determine whether the organisation created that identity for the correct person in the first place.
That makes onboarding part of the cybersecurity architecture rather than simply an HR or service-desk process.
The strongest Zero Trust environment therefore begins before the first login.
If trust is established incorrectly on day one, every control that follows may confidently authenticate the wrong person.
Leave a Reply