Trending
Zero trust fits on a bumper sticker: never trust, always verify. Running it inside a real company — one with legacy applications, contractors, personal phones and a helpdesk that is already underwater — is where most programs stall. The failures are rarely philosophical. They come from the same practical missteps, repeated across industries and company sizes. Here are ten of them, paired with what to do instead.
A vendor demo goes well, a licence gets signed, and the rollout is declared underway. Six months later the tool is switched on, most traffic still flows the old way, and nobody can explain what actually changed.
Products are necessary. They are not the strategy. Before you evaluate anything, write two pages that answer four questions: which assets matter most, what "trust" means for each of them, who is allowed to grant it, and how quickly it can be revoked. Keep that document short enough that people read it. Then map tools to the gaps it exposes, not the other way round. If a purchase decision cannot be traced back to a line in that document, it is probably a distraction.
Ambitious roadmaps that cover every application, device and user in a single quarter tend to collapse under their own dependencies. Pick one workflow with real risk and a manageable number of users — a finance team reaching an internal billing application, for example — and take it end to end. A sensible order looks like this:
The second failure is treating friction as proof of security. An MFA prompt every hour on a laptop in a locked office buys little, while a stolen session token sails straight through. Measure how long a normal task takes before and after a change. If it doubled, people will find a workaround, and the workaround will be worse than what you replaced.
If a control makes the work slower every day, someone will route around it — usually without telling you.
Offer a fast path instead: device trust, passkeys, a session that lasts a working day. The goal is to make secure and easy point in the same direction.
Identity is the strongest signal you have, and it is not the only one. Device posture matters: is the laptop patched, encrypted, running an endpoint agent that checked in this morning? Network and location context matter. So does the sensitivity of what is being requested — reading a public price list and exporting a customer database should not look the same to your policy engine.
Then there are the non-human identities: service accounts, API keys, build pipelines, scheduled jobs. They quietly hold standing access to more than any employee and are rarely reviewed. Inventory them, give each one an owner, and rotate their secrets on a schedule.
A contractor who needed admin rights for two days in March should not still have them in September. Move routine work to just-in-time elevation: request, approval, a defined window, automatic expiry. Keep a documented break-glass path as well, so a genuine outage does not turn into a debate about policy while systems are down.
Policies accumulate. Someone adds an exception for a demo, another for a migration, a third for an executive working from a hotel. Nobody knows whether removing one will break payroll, so nobody removes anything. Give every rule an owner, a purpose and an expiry date, and review the set on a calendar. A rule nobody can explain is a rule nobody can safely delete — which is exactly why it stays for years.
You cannot manage what you do not measure, and zero trust changes the question from "is this network segment trusted" to "should this request succeed right now". Decide what success looks like before the rollout: how many authentications pass on the first attempt, how long it takes to onboard a new hire, how often a manual exception is needed. Track those numbers before and after. Retain logs long enough to investigate an incident that is discovered weeks later, not just hours later.
The security team can write policy. It cannot fix an HR feed that takes five days to mark a leaver, or an application that only speaks a protocol from 2003. Bring in application owners, the helpdesk, identity and access management, networking, and whoever owns the employee data. Give the program a sponsor with budget authority, because the hard parts are usually organisational, not technical.
Passing an audit means you can show a control exists. It does not mean the control works. A rule set copied from a framework can look complete on paper while a stale account with domain admin sits untouched in a forgotten group. Treat the audit as a floor, then ask the harder question: if someone had valid credentials and an ordinary laptop today, what could they reach, and would anyone notice?
Answer that with testing rather than confidence. Run a controlled exercise: have a colleague attempt lateral movement with a test account, or replay a known attack path against the new policies. Then examine the denials that should have been approvals, because false positives are what push people toward workarounds. Treat every policy change like a software release — something to test, monitor and roll back if it misbehaves.
Choose a single, well-understood workflow that touches sensitive data. Map who needs access, from which devices, for how long. Write the policy, pilot it with a small group, watch the telemetry for two weeks, and fix whatever annoys people before expanding. Then repeat with the next workflow.
Ten mistakes make a long list, but most of them share one root: treating zero trust as something to purchase rather than a habit of questioning access, repeatedly, with evidence. Teams that get it right tend to be unglamorous about it — small pilots, named owners, and dull reviews that happen on time. That is the version that survives contact with a real business.
Photo: MasterTux / Pixabay
