A twelve-person bookkeeping firm does not need the security architecture of a bank. It does need to stop treating "connected to the office Wi-Fi" as proof that someone is allowed to open payroll. That single shift is most of what zero trust is. The rest is a handful of controls a small team can put in place without a security department, a compliance officer or a large budget.
What follows is the plain version: what the idea says, why the old approach stopped holding, and the order in which to fix things when you have more laptops than people and no dedicated IT staff.
What zero trust actually says
Every request for access gets judged on its own merits. Who is asking, from which device, for which resource, right now. If the answers hold up, that person gets access to that one thing — not to "the network," and not forever.
That is the entire principle. It usually gets written as "never trust, always verify," which sounds harsher than it is. In practice, zero trust is mostly about narrowing the blast radius. If a laptop is stolen or a password leaks, the attacker should hit a wall quickly instead of finding an open corridor.
The older model worked like a building with one locked front door. Once you were past reception, you could wander. In a small company that meant a single VPN login — or sometimes just the office Wi-Fi password — opened the file server, the billing system, the email archive and the backups. One credential, one mistake, everything gone.
Zero trust is not a product
Vendors sell "zero trust platforms," and some of them are useful. But zero trust is a way of arranging access, not something you buy and install. You can get a long way with settings on the tools you already pay for: your identity provider, your cloud storage, your password manager, your endpoint protection.
Why the front door stopped holding
Three changes did most of the damage. Work left the building, so "inside the office" stopped meaning much — people log in from kitchens, trains and client sites. Credentials became the main target, because phishing a password is cheaper than breaking encryption. And the front door got crowded with contractors, personal phones, interns and that one agency laptop nobody has patched since spring.
None of this makes the perimeter useless. It makes the perimeter insufficient on its own. That is the argument for adding a second question to every access decision: not just "are you on our network?" but "are you, on this device, right now, allowed to do this specific thing?"
The four controls that matter most
Ignore the long checklists for a moment. Almost everything useful in a small environment comes down to four areas.
- Identity. Turn on multi-factor authentication everywhere it is offered, starting with email, cloud admin consoles, banking, the password manager and any code repository. Use single sign-on so people have one strong login instead of fifteen weak ones. Kill shared accounts; if two people know the same password, you cannot tell who did what.
- Devices. You should be able to say which machines are allowed to reach company data. Disk encryption on, automatic updates on, screen lock on, and a way to wipe a laptop that walks out the door. A personal phone checking email is fine; a personal phone holding the customer database is not.
- Least privilege. People get what their job needs and nothing more. Admin rights live in separate accounts, not as an extra button on the daily login. Access to finance folders and production systems is granted in small pieces and reviewed when someone changes roles.
- Visibility. Log sign-ins, permission changes and downloads from sensitive stores. You do not need a security operations centre. You need to notice when an account that has never left the country suddenly signs in from three time zones away, or when someone approves twenty MFA prompts in a row.
A first ninety days, in order
Sequence matters more than speed. Doing these out of order creates work you have to undo.
- Inventory the accounts. List every service holding company data and who can reach it. Expect this to take longer than you want and to surface a few logins for people who left.
- Turn on MFA. Start with the five accounts whose loss would hurt most. Give people two weeks' warning, a clear setup guide and a hardware key or authenticator app that works offline.
- Move to individual credentials. A team password manager with separate vaults, no shared logins, and a documented way to hand over access when someone leaves.
- Add single sign-on. Put it in front of your main SaaS tools. This is what makes offboarding a five-minute task instead of a scavenger hunt.
- Split admin from daily use. Separate accounts for admin work, used only when needed. It is annoying for a week and then it becomes habit.
- Replace broad network access with per-application access. Where your tools allow it, give people a route to the one app they need rather than a tunnel into everything.
- Switch on alerts. A handful of rules — new-country sign-ins, repeated MFA failures, new admin grants, bulk downloads — will catch more than a dashboard nobody opens.
If that list looks like a year of work, pick items one through four and stop. Those four alone remove most of the easy paths an attacker would take.
Where small teams get stuck
The most common mistake is treating zero trust as "deny everything." That produces shadow IT: people share files through personal Dropbox because the approved route takes four clicks and a ticket. If the secure path is slower than the insecure one, the insecure one wins. Every time.
The second mistake is buying a tool before fixing the accounts. An identity-aware proxy in front of a shared login with no MFA is a locked gate attached to a missing fence. Fix the credentials first; the shiny product works better afterwards anyway.
The third is treating it as a project with an end date. Access drifts. People change roles, contractors stay longer than planned, a new SaaS tool gets adopted by one team on a credit card. Zero trust is a habit of asking whether an access grant still makes sense, not a migration you finish.
How to tell it is working
You can answer "who can see the client contracts?" in a few minutes rather than a few days. Offboarding someone takes an afternoon, and you are confident nothing was missed. A phished password alone is no longer enough to get in. Admin rights are the exception, not the default. You have a written break-glass procedure for the day the identity provider itself is down, so nobody panics and starts handing out shared passwords.
If you handle regulated information — health records, card payments, student data — check what your obligations actually require, and get qualified advice rather than relying on a blog post, including this one.
Start with the account you would least like to lose
Pick that one account tonight. Turn on multi-factor authentication. Give it its own password, stored in a manager rather than in someone's memory. Write down who else can get in, and remove anyone who should not. Then do the same for the next account tomorrow.
That is zero trust in miniature: a specific person, a specific device, a specific resource, verified each time. Scale the habit up and you have an architecture. Skip the slogans — they were never the useful part.
Photo: panumas nikhomkhai / Pexels
