Practical Zero Trust Access for a 5-Person Engineering Team on a $9/mo Budget

Most Zero Trust articles for small teams read like enterprise procurement plans.

Pick a ZTNA vendor. Talk to sales. Plan a 90-day rollout. Configure SAML, connect an IdP, integrate an EDR, write policy-as-code, and assign someone to maintain it.

That works when you have a security team.

It does not work as well for a five-person startup where the CTO is also the IT admin, the security engineer, and the person who created the staging server last Tuesday.

This post walks through a practical setup: identity-bound private networking, least-privilege access rules, optional device posture checks, and per-device enforcement for a five-person engineering team — starting at $9/month.

What "Zero Trust" actually means here

Before the walkthrough, a working definition. Zero Trust is "never trust the network, always verify the device and the user." In practical terms:

1. No flat network. Just being on a corporate Wi-Fi or VPN doesn't grant access to anything.
2. Every network path is authorized before traffic is allowed. Application-layer authentication, such as SSH keys or Grafana login, still remains the responsibility of the destination service.
3. Posture matters. Access is conditional on the device being in a known-good security state (EDR running, OS patched, disk encrypted).
4. Least privilege by default. Each rule grants the narrowest possible access.

For a five-person team, this stack is achievable in an afternoon.

The team's actual stuff

The hypothetical (but realistic) team:

• 5 engineers, all on MacBooks
• A staging server (Linux box on AWS) that runs the dev database
• A production database (also Linux, on AWS, more locked down)
• A shared Grafana instance for metrics
• A Linkding bookmark manager that the team uses as an internal wiki

The goal: only engineers on healthy MacBooks can SSH to staging. Only the CTO can SSH to production. Everyone on the team can reach Grafana. Linkding is exposed via a public URL — anyone can hit the URL, but Linkding's own authentication still controls who can sign in.

The $9/month access stack

The HostAnywhere Developer plan is $9/month flat, not per user. It covers 5 members, 100 devices, Access Control rules, and posture-based conditions using integrations such as CrowdStrike Falcon or Microsoft Intune.

Important distinction: HostAnywhere does not replace your EDR or MDM. It consumes posture signals from tools such as CrowdStrike or Intune and uses those signals in access policy decisions.

So the budget looks like this:

• HostAnywhere Developer: $9/month
• EDR/MDM: use what you already have, or budget separately
• Servers: whatever you already run in AWS, a home lab, or another environment

If you already have CrowdStrike, Intune, or another supported posture source, the access-control layer is $9/month flat for the team.

At the time of writing, many ZTNA and mesh access products use per-user pricing. That model can work well, but it scales linearly as the team grows. HostAnywhere uses per-network pricing instead, so your access-control cost does not increase one-for-one with every new engineer. Always check current vendor pricing pages before relying on any comparison for budget planning.

The walkthrough

Step 1: Install the agent on every MacBook (5 minutes per laptop)

Each engineer downloads the HostAnywhere agent from hostanywhere.io/download, runs the installer, signs in with their own account.

Each MacBook gets a private IP in the 100.64.x.x range. They join the team's network automatically because the CTO invited them.

Step 2: Install the agent on the servers (5 minutes per server)

SSH into staging, install the Linux build, sign in once with a token from the dashboard. Same for production. Same for the Grafana and Linkding servers.

Now every device — laptops and servers — is on the team's private mesh and has a stable mesh IP.

Step 3: Connect CrowdStrike Falcon (10 minutes, one-time)

In the HostAnywhere dashboard → Integrations → CrowdStrike Falcon. Paste a Falcon API client ID and secret (read-only, scoped to ZTA data).

HostAnywhere starts polling Falcon every 5 minutes for each device's Zero Trust Assessment (ZTA) score. The dashboard now shows a posture column next to each MacBook: ZTA 89, ZTA 76, ZTA 92, and so on.

Step 4: Tag devices

Tag every engineer's MacBook team:engineers. Tag the CTO's MacBook additionally with team:cto. Tag the staging server service:staging. Tag production service:prod. Tag Grafana service:grafana. Tag Linkding service:linkding.

Step 5: Write the rules

In the dashboard → Access Control. The initial policy is five rules:

1. Allow team:cto → service:prod on tcp/22 when posture.falcon.zta >= 75
2. Allow team:engineers → service:staging on tcp/22 when posture.falcon.zta >= 75
3. Allow team:engineers → service:grafana on tcp/3000
4. Allow team:engineers → service:linkding on tcp/8080
5. Deny everything else by default

That is the entire access model. Engineers reach staging, Grafana, and Linkding. The CTO additionally reaches production. Anything else is denied.

The posture conditions on rules 1 and 2 mean: even if the engineer is on the mesh and tagged correctly, if their CrowdStrike ZTA score drops below 75 (e.g., Falcon sensor is unhealthy, disk encryption is off, OS is unpatched), the rule no longer matches, and SSH gets blocked.

Step 6: Expose Linkding publicly (optional, 2 minutes)

The team wants Linkding reachable from outside the office for the occasional offline reading session. Create a public service URL: linkding.hostanywhere.io → mesh IP of the Linkding box, port 8080. HostAnywhere handles TLS at the edge. For this example, the public URL is protected by Linkding authentication. If the service itself does not have strong authentication, do not expose it publicly without adding an authentication layer.

What this stack catches

Concrete scenarios this setup handles correctly:

• A laptop is stolen. The thief signs in to a fake account; their laptop isn't tagged team:engineers. No rule matches; no SSH. Even if the thief sees a HostAnywhere agent installed, they can't reach any tagged service.
• An engineer's laptop gets infected. Falcon's ZTA score drops because the EDR is detecting suspicious behavior. The rule's posture condition (>= 75) stops matching within ~5 minutes (the posture cache refresh window). SSH access to staging is gone until the device returns to a known-good state.
• A contractor needs temporary staging access. Invite them as a member (counts toward 5-member limit on Developer), tag their device team:engineers, they get staging access for the engagement, remove them when done.
• The CTO leaves; the new CTO takes over. Reassign the team:cto tag from one device to another. Production access transfers with the tag.

What this stack doesn't catch

Honest about gaps.

• DNS exfiltration. HostAnywhere controls who reaches what, not what data flows once a session is allowed. Engineers with staging access can copy data out of staging if they want to. You need a separate DLP layer for that.
• Lateral movement inside an allowed session. Once SSH to staging is allowed, the rule doesn't filter commands. You'd want host-based auditing (auditd, osquery) for that.
• Identity-spoofing at the SSH layer. The mesh ensures only authorized devices reach SSH. SSH itself still needs proper key management on each server.

The point isn't that HostAnywhere is a complete security stack — it's the network-and-identity layer. Combine it with the EDR you already have and the audit logging your servers do, and you have a defensible posture for a 5-person team.

What I would still add later

For a five-person team, this is a strong starting point. As the company grows, I would add:

• SSO with Google Workspace, Okta, or Microsoft Entra
• Centralized server audit logs
• SSH certificate-based access or stronger SSH key lifecycle management
• DLP for sensitive database exports
• Formal offboarding workflows
• Alerting when posture checks fail

The point is not to build the entire enterprise security stack on day one. The point is to avoid the biggest mistake small teams make: giving everyone broad network access because narrower access feels too hard to operate.

When this stops working

The $9/month Developer plan covers 5 members and 100 devices. As the team grows, you can move to the Team plan. Once you need SSO with Google Workspace, Okta, or Microsoft Entra ID, that belongs on the Team plan. Once you cross 200 devices, you're looking at Enterprise.

But the architecture stays the same. The rules you wrote on day one still apply on day 1,000. You're not paying for a migration.

Try it

Try HostAnywhere Free at hostanywhere.io — 10 devices, no credit card. The free tier is enough to wire up the architecture above for a 3-person team; upgrade to Developer ($9/mo) when you add posture conditions and integrations.