Identity Is the New Perimeter: Practical Zero-Trust for Mid-Size Companies

"Zero-trust" is the security industry's most over-marketed phrase. It is also the most operationally useful idea introduced in the last decade if you can ignore the marketing and focus on what it actually demands. The catch is that the implementation depth most vendors imply (continuous device posture, microsegmentation everywhere, signed-and-attested workload identity) is genuinely outside the budget envelope of most mid-size companies, and trying to skip ahead to the architecture diagram on a vendor's slide produces an expensive programme that never lands.

This is the version of zero-trust we run with mid-market clients. It costs roughly a quarter of the headline number on most vendor slides, takes about 18 months to land, and demonstrably reduces lateral-movement risk by every measure we have. It is also opinionated about which parts of the canonical zero-trust architecture you can defer.

What zero-trust actually means in plain English

Zero-trust is one assertion: every access decision is made fresh, against a current view of who is asking and what they are allowed to do, with no assumption that "being inside the network" grants any privilege. That is it.

Everything else, mTLS between every workload, ZTNA in front of every internal app, signed device posture attestations, attribute-based access control with policy-as-code, those are implementation patterns for that assertion. They are not the assertion. You can be in compliance with zero-trust without all of them, and you can have all of them without being in compliance with zero-trust.

The reason this matters is that mid-size companies regularly buy the implementation patterns and skip the underlying decision logic. The result is an identity programme that has SSO, conditional access, MFA, ZTNA, and a CIEM tool, but still cannot answer the question "if a contractor's laptop is compromised right now, what production data can they reach in the next ten minutes?" The implementation is in place; the access decision logic is not.

The four moves that close most of the realistic attack surface

In our experience across roughly 40 mid-size identity programmes, four engineering decisions account for ~80% of the actual reduction in lateral-movement risk. The remaining 20% is genuinely expensive and you should consider it carefully.

1. Make IdP the only path to anything

The single highest-value move is to ensure every meaningful resource (production cloud, code repos, CI/CD, internal apps, databases, ops tooling, Kubernetes, vendor SaaS) requires authentication via your central identity provider. Every other path, local accounts, shared service accounts, vendor-issued credentials, federated identity from old acquisitions, must be either eliminated or routed through the IdP.

This is hard for one reason: there are always exceptions. Legacy SaaS that doesn't support SAML. Database engines with their own auth. Vendor consoles bought by procurement before security got involved. The exceptions are where the risk lives. Inventory them, prioritise them by blast radius, and close them on a measured timeline. The first round usually finds 30 to 80 unmanaged auth surfaces in a typical mid-size company.

2. Conditional access policies that actually express your risk model

Most conditional access policies we see are blunt: "require MFA for all users, block sign-ins from outside known countries." This is fine but doesn't differentiate between an HR analyst checking pay slips and a DevOps engineer assuming a production role. The right granularity is per-application, sometimes per-action.

A reasonable starting point is three policy classes:

• Standard work: SSO, MFA, modern auth required. Browser session can persist for the working day.
• Sensitive systems (production cloud admin, financial systems, source code with secrets, customer data plane): SSO, hardware-backed MFA, managed-device attestation, fresh authentication every 4–8 hours, no impossible-travel.
• Highest-trust actions (production deployment, IAM policy changes, key rotations, data export above a threshold): explicit step-up auth at the action, justification required, recorded in an immutable audit stream.

This three-tier model is enforceable with what most enterprise IdPs ship today (Entra ID, Okta, Ping). It does not require additional tooling. What it requires is the discipline to actually map every system into one of the three tiers, which is the real work.

3. Privilege graph on a weekly cadence

Do not ask "do users have least privilege?" That question never closes. Ask instead: "for every privilege relationship in our environment, do we know it exists, and is it justified?" The way to operationalise this is to compute the privilege graph (every principal → every resource it can reach) on a weekly cadence and track its size and shape over time.

A healthy programme sees this graph shrink. An unhealthy one sees it grow as engineering teams add scope to make systems work. The CIEM space exists to do this for cloud; for SaaS and internal apps you can usually build a 90%-correct version from API exports plus a normalisation layer. The point is not perfection; the point is producing a metric that exposes whether the programme is gaining or losing ground.

4. Action-level audit, not session-level audit

Most identity programmes log authentication events. Few log authorisation decisions. The difference matters because almost every real incident plays out as a sequence of authorised actions: the attacker authenticates as a legitimate user, then performs actions that user could perform, just at a velocity or pattern that would have been detectable. Without action-level logs, the post-incident reconstruction is forensic guesswork.

Action-level audit at minimum should cover: cloud control plane (CloudTrail / Activity Log / Audit Logs), identity admin (role assignments, policy edits, privileged group changes), production deployment, secret access, and customer data exports. These are the places where attacker actions are visible if you are looking. Most of the spend here is the SIEM ingestion cost; the engineering work is mostly enabling logs that already exist.

The 20% that is genuinely expensive

If you do the four above, you have closed roughly 80% of the realistic lateral-movement attack surface for a mid-size company. The remaining 20% is the part where vendor marketing lives, and it is genuinely costly:

• Continuous device posture and attestation. Hardware-rooted device identity that proves the requesting machine has not drifted from a known-good state, evaluated on every access, is real zero-trust at the network layer. It is also the single largest line item in a Google-style zero-trust deployment. Mid-size companies rarely need this, and the ones that do (regulated industries with high-value targets) should plan a multi-year roadmap rather than buy it as an off-the-shelf solution.
• Workload identity at full granularity. Mutual TLS between every microservice with rotating short-lived certificates is excellent engineering. It is also expensive and, for most companies, lower-value than fixing the human-identity surface first. Service mesh implementations frequently get bought before the four above are done, and the resulting complexity actually increases incident-response difficulty.
• Microsegmentation throughout the network. Network-layer enforcement of identity-aware policy is a real control, but if you have already made identity the perimeter (move 1), the network can be flatter and the control returns are smaller.

A pragmatic mid-size identity programme defers all three of these for the first 18–24 months and revisits when the underlying graph and audit are healthy. Buying them earlier is not wrong, it is just the wrong sequence.

Where this connects to our practice

Pelican Tech's Identity & Access Management practice builds the four-move programme above with tooling clients already own (Entra ID / Okta / Ping for IdP, AWS / Azure / GCP CIEM for cloud privilege graphs, the existing SIEM for action-level audit). We work alongside our cloud security team when the privilege graph crosses cloud and on-prem boundaries, and with our SIEM/SOAR specialists to make sure action-level audit becomes detection rather than data-lake storage.

If your identity programme has all the implementation patterns of zero-trust but cannot answer the contractor-laptop question above, that is the engagement to start with.