SECURITY
What a Zero Trust consultant actually does in the first 30 days
6 min read
The first month of a Zero Trust engagement should produce a measured baseline of identity, device and access rather than deployed controls, because enforcing policies before you know who and what they will affect is how rollouts get rolled back.
Zero Trust engagements go wrong in a predictable way. A policy is designed from the reference architecture, applied, and blocks a group of people nobody realised were in scope. The policy is reverted and the programme loses a month and most of its credibility.
Almost all of that is avoidable by spending the first four weeks measuring rather than deploying. Here is what those weeks should contain.
Week one: identity, completely
Everything in Zero Trust resolves to identity, so the first task is a full account inventory — not just staff, but guests, service accounts, shared mailboxes, application identities and anything else that can authenticate.
The useful output is not the count. It is the list of accounts that can sign in and have no clear owner, because those are both the largest risk and the easiest early win.
- Every account that can authenticate, with an owner against each
- Multifactor coverage, and specifically the list of exemptions and the reason for each
- Privileged roles: how many, how permanent, and whether any are shared
- Legacy authentication: what is still using it and what would break if it stopped
Week two: devices and the access paths
The second question is what is connecting. Managed devices are straightforward to enumerate. The interesting part is the gap between the device count and the people count, which is where unmanaged and personal devices live.
Alongside that, the access paths: which applications are reached through the identity provider, which have their own separate credentials, and which are exposed to the internet without being behind either.
Week three: measure the policies you have not applied yet
This is the week that saves the project. Conditional Access policies are written and deployed in report-only mode. They enforce nothing and log what they would have done.
After a week of real traffic, the logs answer the question that normally gets answered by an outage: exactly who would have been blocked, from where, on what device, doing what. Every surprise in that report is a surprise that did not become an incident.
Week four: the changes that are safe now
Some things do not need to wait for the full programme. Removing accounts with no owner, enabling multifactor for administrators, creating break-glass accounts and blocking legacy authentication for groups confirmed not to use it are all low-risk and high-value.
These get done in week four, with the report-only data behind them. The rest becomes a sequenced plan with the measured impact attached to each step, which is a very different document from a plan built on an architecture diagram.
What the engagement should produce
A written baseline of identity, device and access. A report-only measurement showing the real impact of the proposed policies. A short list of changes already made. And a sequence for the rest, ordered by risk reduced per unit of disruption.
What it should not produce in thirty days is a fully enforced Zero Trust architecture. Anyone offering that has either inherited an unusually tidy environment or has not measured yet.
Questions we get asked
What does a Zero Trust consultant actually do?
They establish what your current identity, device and access position is, measure what proposed controls would do before those controls are enforced, and then sequence the rollout so each step is reversible. The deployment work itself is a smaller part of the engagement than most people expect.
Is a Zero Trust engagement worth it for a smaller organisation?
The principles scale down well, because they are mostly about identity discipline rather than expensive tooling. A smaller organisation typically needs a shorter assessment and a shorter sequence, not a different approach.
How disruptive is the first month?
Close to zero if it is run as described. Report-only policies enforce nothing, and the inventory work is read-only. The disruption, where there is any, comes later and is sized in advance by the week three measurement.