Zero Trust With Two IT Staff and the Licences You Already Own

Zero Trust guidance is written for organisations with a security team. Mid-market companies do not have one. They have two or three IT people who also run the help desk, a budget approved annually, and a production environment nobody can take offline to re-architect.

That changes the problem entirely. The architecture is not in dispute — if you want the model itself, the five pillars are covered in Zero Trust in Practice. This is about the constraint: what you can actually achieve with the people and licences you already have, in what order, and what to leave until later.

Start with what you are already paying for

The most common mid-market mistake is buying a Zero Trust product before switching on the capability already sitting in an existing subscription.

If you run a business-tier productivity suite, you very likely already own:

• a single identity provider with single sign-on
• conditional access policies
• multi-factor authentication, including phishing-resistant methods
• device compliance and management
• basic data classification and protection

Deployed, these cover a substantial share of a Zero Trust programme. Unlicensed products bought to duplicate them are the most expensive line in a failed rollout.

Do this first: list every security capability included in your current licences, then mark each as deployed, partially deployed, or not deployed. In our experience most mid-market organisations find between a third and half of what they already pay for is not switched on.

That audit is free, takes a morning, and frequently removes the need for the first purchase anyone proposed.

The order that fits a small team

Sequencing matters more when there is no capacity for parallel work. One thing at a time, each delivering standalone risk reduction so stopping early still leaves you better off.

Months 1–2: identity. Consolidate authentication behind one provider. Block legacy authentication. Enforce MFA, phishing-resistant for administrators first. Create break-glass accounts before writing any policy.

This is the phase with the highest return per hour of effort, and it is almost entirely configuration rather than procurement.

Months 3–4: privileged access. Remove standing administrator rights. Vault credentials and broker elevation so admin access is temporary and recorded. Small teams often resist this because they are the administrators — which is precisely why it matters: two people with permanent domain admin is two accounts between an attacker and everything.

A privileged access management approach does not require enterprise tooling at this size. Named accounts, no shared credentials, elevation on request and logging gets most of the value.

Months 5–7: device trust. Enrol devices in management, enforce compliance, then require a compliant device for access to anything sensitive. Do it in rings. The unmanaged contractor laptop will surface here, and it is better to find it now.

Months 8–10: segmentation where it pays. Full microsegmentation is not a mid-market project. Separating the things that genuinely must not reach each other is: guest networks, printers and embedded devices, finance systems, backup infrastructure. Four or five boundaries, done properly, gets most of the blast-radius reduction.

Months 11–12: replace remote access. Move from a flat VPN to per-application access. This is usually the first genuine purchase, and it is worth more once identity and device trust are in place — which is why it is last rather than first.

What to defer, deliberately

Zero Trust reference architectures list capabilities most mid-market organisations should not attempt in year one:

• Microsegmentation to workload level. High effort, needs sustained ownership.
• A full data classification programme. Start with the few data types that carry obligations, not a taxonomy.
• Continuous risk scoring across every signal. Valuable with a team to tune it, noise without one.
• Replacing tooling that works because a vendor's diagram has a different box.

Deferring these is not a compromise. It is the recognition that a control nobody has time to operate is not a control — it is an expense with an alert queue nobody reads.

Who actually does the work

The resourcing question is where mid-market programmes quietly fail. Three honest options:

Internal, sequenced. Your team does it, one phase at a time, with other work paused. Realistic only if someone will actually protect the time — otherwise phase one takes nine months.

Co-managed. A provider does the implementation, your team operates it afterwards with support. The common middle, and usually the right answer when the team is two or three people.

Outsourced operation. Someone else runs identity, device compliance and monitoring day to day. Appropriate where there is no realistic internal capacity, and the thing to check is what happens at 2am on a Saturday.

What does not work is assigning the programme to someone's spare capacity. There is no spare capacity on a two-person team; there is only work that displaces other work. Decide what gets displaced, or the programme stalls after the first phase.

Measuring it without a security analyst

Four numbers, reviewed monthly, that need no specialist tooling:

• Accounts without phishing-resistant MFA. Target zero for administrators first.
• Standing privileged accounts. Target: only break-glass.
• Devices not enrolled or not compliant. The trend matters more than the number.
• Applications still reachable without going through the identity provider. Each one is a bypass.

All four come from consoles you already have. If all four are falling, the programme is working, whatever the architecture diagram says.

The honest timeline

Twelve to eighteen months for a mid-market organisation doing this alongside its normal workload. The first two phases carry most of the risk reduction and should take four months.

Anyone promising a Zero Trust transformation in a quarter is either selling a product and calling it an outcome, or describing an organisation with a security team you do not have.

The constraint is not knowledge. The architecture is well documented and not controversial. The constraint is people, and a plan that ignores that is a plan that stops in month three.