Zero Trust Security for Small Engineering Teams

Zero trust is sold as a product category and defined as an architecture principle, and the gap between those two things is where small engineering teams waste money. The actual reference document, NIST Special Publication 800-207, is architectural guidance that recommends no product and names no vendor. Read it and the work for a ten-person team turns out to be mostly identity plumbing you can finish in a quarter.

What SP 800-207 actually says

NIST SP 800-207, published in August 2020, defines the term precisely:

“Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.”

Two phrases in that sentence do all the work. Per-request means the decision is re-made every time, not once at connection setup. A network viewed as compromised means you stop treating “inside the VPN” as evidence of anything. The document is blunt that this is not something you buy: “ZT is not a single architecture but a set of guiding principles for workflow, system design and operations.”

Section 2.1 lists seven tenets. Abbreviated, they are: all data sources and computing services are resources; all communication is secured regardless of network location; access to individual resources is granted per session; access is determined by dynamic policy including the observable state of client identity, application and requesting asset; the enterprise monitors and measures the integrity and security posture of all owned and associated assets; all resource authentication and authorization are dynamic and strictly enforced before access is allowed; and the enterprise collects as much information as possible about the current state of assets, infrastructure and communications.

The architecture has three logical components. A policy engine makes the grant or deny decision. A policy administrator establishes and tears down the communication path once the engine has decided. A policy enforcement point sits in the data path and actually stops traffic. In a small shop the policy engine is usually your identity provider’s conditional access rules, and the enforcement point is a proxy or a service mesh sidecar. You do not need three separate products, but you do need to know which of your tools is playing which role, because a zero trust story with no enforcement point is a slide deck.

Identity-aware proxies versus the VPN

A VPN authenticates a device onto a network and then, in most small deployments, gets out of the way. That fails tenet three immediately: one authentication event grants an open-ended lease on a routable network segment, and a stolen laptop or a compromised CI runner inherits the whole thing. Lateral movement in almost every incident report of the last decade depends on exactly that property.

An identity-aware proxy inverts the model. It terminates the connection, evaluates the user’s identity, group membership, device state and request context, and then forwards the specific request to the specific application. There is no network to join. Google’s BeyondCorp is the best-documented production example of the pattern, and every commercial equivalent is a variation on it.

The honest caveat: proxies are strongest for HTTP services and awkward for SSH, database clients and legacy TCP. Most teams end up running an identity-aware proxy for internal web apps and admin panels, and a narrow, short-lived, certificate-based path for shell and database access. That is a better outcome than one flat VPN, and it is achievable without replacing your network.

Device posture, without buying an MDM platform first

Tenet five asks you to measure the posture of every asset. For a ten-person team the minimum viable version is: every laptop is enrolled in something that can report disk encryption state, OS patch level, screen lock and whether endpoint protection is running; that signal reaches your identity provider; and your conditional access policy refuses sign-in to production systems from an unenrolled or non-compliant device.

Notice what that does not require. You do not need application allowlisting, remote wipe workflows or a dedicated security engineer. What you need is the posture signal joined to the access decision, because posture data that only appears on a dashboard satisfies nobody’s threat model. The same logic applies to CI runners, which are unmanaged Linux boxes with production credentials and are routinely the weakest asset in a small company’s estate.

Service identity and mTLS

Users are the easy half. Service-to-service calls inside your own infrastructure usually authenticate with a long-lived static token in an environment variable, which is the exact pattern zero trust exists to remove.

NIST SP 800-207A, published in September 2023, extends the model to cloud-native applications and is the more useful document if you run containers. It argues for identity-based segmentation, where policy is grounded in identities associated with users, services and devices rather than network location, and it recommends cryptographically verifiable, short-lived service identities. Concretely, it points at SPIFFE, where a SPIFFE ID uniquely identifies a workload and is encoded as a URI inside an X.509 certificate. Service authentication then happens “at the connection level via mutual Transport Layer Security (mTLS) when a service makes an initial connection establishment,” and the document suggests bounding connection lifetime to the certificate TTL or roughly 15 to 30 minutes so that authorization is genuinely re-evaluated.

It also names the enforcement points in a Kubernetes-shaped deployment: sidecar proxies for intra-cluster traffic, ingress gateways for traffic entering the cluster, and egress gateways for outbound calls. If you already run a managed service mesh, most of this is configuration rather than construction. If you run three services on VMs, issuing short-lived certificates from a private CA and turning on mTLS between them gets you the same property for far less operational weight.

An adoption order for a ten-person team

NIST’s own implementation guide, SP 1800-35, finalised on 11 June 2025, documents 19 example zero trust builds assembled with 24 collaborating vendors. It is worth skimming for patterns, but the builds assume enterprise budgets. For a ten-person team, sequence it by how much risk each step removes per week of work.

1. One identity provider, no exceptions. Every internal tool authenticates through it via SSO. Kill local accounts and shared logins. Nothing downstream works without this.
2. Phishing-resistant MFA on that IdP, enforced for everyone, with WebAuthn passkeys or hardware keys for anyone holding admin rights. Push-approval MFA does not survive a modern proxy phishing kit, because the proxy simply relays the approval; a WebAuthn signature is bound to the attacker’s own origin and fails.
3. Inventory and enrol every device, including CI runners and any personal machine touching source code. Feed posture into the IdP.
4. Move internal web apps behind an identity-aware proxy and delete the VPN routes to them. Start with the two or three apps most people use, so the migration proves itself.
5. Replace standing cloud credentials with short-lived, role-based access issued through the IdP. Long-lived access keys in developer laptops and CI secrets are the highest-value target you own.
6. Turn on mTLS between your own services and drop shared static service tokens. Keep certificate TTLs short.
7. Centralise logs from the IdP, the proxy and the cloud control plane into one queryable place, and write three alerts you will actually read.
8. Re-run access reviews quarterly and treat drift as a defect, not a compliance chore.

Steps one through three remove most of the realistic attack paths against a company that size. Steps four through six are where the architecture becomes genuinely per-request. Step seven is what turns an incident from a mystery into a timeline.

The trap to avoid

The failure mode for small teams is buying a product labelled zero trust, deploying it beside an unchanged VPN, and leaving both running. You now pay twice and the weaker path still exists, which means your effective security is the VPN’s. SP 800-207 is a set of principles about where decisions get made and how often; the test of whether you have adopted them is not what you bought but whether any single authentication event still grants open-ended network access to anything. If it does, start there and ignore the product catalogue until it does not.

Sources

• NIST — SP 800-207, Zero Trust Architecture (August 2020)
• NIST — SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications
• NIST CSRC — SP 1800-35, Implementing a Zero Trust Architecture
• NIST NCCoE — NIST Publishes Final SP 1800-35
• NIST CSRC — SP 800-207A publication record
• Google Cloud — BeyondCorp zero trust enterprise security
• W3C — Web Authentication Level 3 (phishing-resistant authentication)