m@ksim.pro
Back to all posts
Security 3 min read

Zero trust: what it means in practice for a mid-size company

Zero trust has become a buzzword. Behind it is a genuinely useful access model - but getting there requires specific decisions, not just a policy statement.

"We are moving to zero trust" is a phrase I hear regularly now, usually from managers who have read a vendor whitepaper or a post-incident review. Less frequently do I hear a concrete description of what will change. That gap is where most zero trust initiatives stall.

Zero trust is not a product. It is an access design principle: do not trust any request by default, regardless of where it originates. Verify identity, verify device, verify context - every time, for every resource. The practical implementation of that principle is what is hard, and it is worth being specific about what it requires.

What zero trust is replacing

Traditional network security is built on a perimeter: inside the network is trusted, outside is not. VPN extends that perimeter to remote users. If you are inside - or connected via VPN - you can access resources your account is authorised for, often with broad lateral movement across the internal network.

This model has a clear weak point: once an attacker is inside, they move freely. The CrowdStrike outage and many ransomware incidents share this pattern - an initial compromise that then spreads unchecked through a flat internal network.

Zero trust replaces perimeter trust with continuous verification. The question is not "is this request coming from inside the network?" but "can this specific identity, on this specific device, in this specific context, access this specific resource right now?"

The four things you actually need to implement

The principle sounds clean. The implementation has four concrete requirements.

Identity. Every user and every service needs a strong, managed identity. This means a directory (usually an IDP like Azure AD, Okta, or Google Workspace), enforced MFA for all human users, and service accounts with scoped permissions rather than shared credentials.

Device trust. The device making the request needs to be in a known state. This typically means device management (MDM) that can verify patch level, disk encryption, and endpoint protection status before granting access.

Least-privilege access. Resources should be segmented and accessible only to the identities that need them. In practice, this means reviewing and tightening existing permissions, which is often the most politically difficult part.

Continuous verification. Session trust should not be assumed from a single login. Short-lived tokens, periodic re-authentication for sensitive operations, and anomaly detection are the mechanisms here.

Where to start without rebuilding everything

Most mid-size companies cannot implement all of this at once, and should not try. A practical sequence:

  1. Get identity in order first. If you do not have a central IDP with enforced MFA everywhere, that is the single most impactful step and it is achievable quickly.
  2. Audit what is accessible to everyone on the internal network. Segment the highest-risk systems first - finance, HR, source code repositories, production infrastructure.
  3. Introduce device posture checks for access to critical applications. Most modern IDPs support this without replacing your entire infrastructure.
  4. Replace broad VPN access with application-specific access for remote users. ZTNA (zero trust network access) tools have become affordable and deployable without full infrastructure replacement.

None of these steps requires a full architectural overhaul. Each one measurably reduces the blast radius of a compromise.

The part that is always harder than the technology

In my experience, the technology for zero trust is available and affordable. The hard part is organisational: someone has to own access review, someone has to enforce tightening permissions when it creates friction, and leadership has to accept that security and convenience trade off.

Zero trust does not fail because the tools do not work. It fails because nobody decided who owns access governance on an ongoing basis.

Back to all posts
Contact

If this resonated, write to me. I reply personally.

WhatsApp