Zero trust has an image problem. It sounds like a two-year programme with a consultancy attached, so small teams file it under things we will do when we are bigger.
The truth is less impressive and more useful. Most of the benefit comes from a handful of changes you can make in a month, and almost none of them require a new product.
What It Actually Means
One sentence: stop trusting anything because of where it sits on the network. Verify identity and device on every request, and grant the least access that works.
The old model was a castle with a moat. Once inside, you were trusted. That model died the day the first laptop left the office, and it has been quietly rotting ever since.
Week 1: Identity
Everything starts here. If identity is weak, the rest is decoration.
- Consolidate to one identity provider. Every app that can use single sign-on should. Local accounts are where breaches hide.
- Phishing-resistant MFA for admins. Hardware keys or passkeys, not SMS. Admins first, everyone else next month.
- Audit OAuth grants. Look at what third-party apps can read. This one afternoon usually produces the biggest surprise of the whole project.
- Kill shared accounts. If two people know the password, you have no audit trail and no offboarding story.
Week 2: Access
Now reduce what each identity can reach.
Start by listing who has administrator rights and cutting it to the people who genuinely need it today. Then remove standing access to production for anyone who does not deploy. Time-bound elevation beats permanent privilege, and most identity providers now support it without extra tooling.
Do not attempt full role-based access control in week two. Cut the obvious excess, document what you did, and move on.
Week 3: Devices
A verified identity on a compromised laptop is still a compromise.
Require managed or registered devices for anything sensitive. Enforce disk encryption, screen lock and automatic updates. Then handle contractors deliberately, because unmanaged devices with full access is the single most common gap in small companies.
Week 4: Visibility and the AI Layer
You cannot verify what you cannot see. Centralise authentication logs, alert on impossible travel and unusual admin activity, and test that someone actually receives the alerts.
Then extend the same thinking to your agents, because they are identities too. Every AI agent with access to your systems needs a named owner, a scoped credential, and a log of what it did. An unscoped agent token is a standing privilege that never sleeps and never gets offboarded.
The 30-Day Scorecard
| Check | Target |
|---|---|
| Apps behind single sign-on | Over 90% |
| Admins on phishing-resistant MFA | 100% |
| Standing production access | Only those who deploy |
| Unmanaged devices with sensitive access | Zero |
| Agents with a named owner | 100% |
| Auth logs centralised and alerting | Yes, and tested |
Conclusion
Do identity in week one, access in week two, devices in week three and visibility in week four. Skip the architecture diagrams, skip the vendor evaluation, and treat your AI agents as identities that need owners and scoped credentials. A small team that completes this month is meaningfully harder to breach than one still planning a two-year programme.
Frequently Asked Questions
Do we need to buy a zero trust product?
Usually not at this stage. Most of the first month uses capabilities already sitting in your identity provider and device management, unused.
What if we cannot get everyone on MFA quickly?
Start with admins and anyone touching finance or customer data. Partial coverage of the highest-risk accounts beats a stalled all-or-nothing rollout.
How does this apply to AI agents?
Treat each agent as a user. Named owner, scoped credential, logged activity, and an offboarding step when the agent is retired. Orphaned agent credentials are the audit finding of the next few years.