Zero Trust for Small Business: A Practical Guide

Zero trust was invented by a Forrester analyst in 2010 to describe network security architecture for large enterprises with complex, distributed infrastructure. It was popularized by Google's BeyondCorp initiative, which required massive internal investment to implement. For the next decade, "zero trust" primarily meant something that Lockheed Martin and JPMorgan Chase implemented.

Then security vendors figured out that "zero trust" could be applied to any product with an authentication component, and suddenly every identity provider, VPN replacement, and endpoint detection tool was a "zero trust solution."

The result: most small businesses that research zero trust conclude either that it's too complex for their stage, or that they've already implemented it by buying a particular product. Both conclusions are usually wrong.

This guide strips out the vendor marketing and explains what zero trust actually means for a 50-person company, what five things you actually need to implement, which tools work at SMB scale without a dedicated security team to run them, and what you can skip entirely at your stage.

---

What Zero Trust Actually Means

The core principle is straightforward: never trust, always verify.

Traditional network security operated on the assumption that everything inside the network perimeter was trustworthy and everything outside was not. If you could connect to the corporate VPN, you were considered a trusted user and could access resources. This worked when employees sat in offices and applications ran in on-premises data centers.

It doesn't work when:

• Employees work from home, coffee shops, and airports
• Applications run in SaaS (Salesforce, GitHub, AWS) outside any corporate perimeter
• Contractors and vendors need access to specific internal resources
• A phished employee credential gives an attacker the same "trusted" access as the employee

Zero trust replaces perimeter-based trust with identity-based trust. Instead of "you're on the network, so you're trusted," the model becomes:

1. Verify identity — who are you, and can you prove it? (Not just a password — MFA, device health, location context)
2. Verify device — is this a managed, compliant device? Or an unknown personal laptop?
3. Verify access context — should this specific identity have access to this specific resource right now?
4. Apply least privilege — grant the minimum access required for the specific task, not broad access to everything

For a 50-person company, implementing this fully doesn't require a $500K enterprise security platform. It requires the right four or five tools, configured correctly, with clear policies.

---

The SMB Reality Check

Before the implementation steps, a grounding point on what's realistic.

What zero trust is at your scale:

• Strong identity verification (MFA everywhere, single sign-on to applications)
• Device management (you know what devices are accessing your systems)
• Least-privilege access (people have access to what they need, not everything)
• Continuous verification (access is re-evaluated, not assumed persistent)

What zero trust is not at your scale:

• Full microsegmentation of every network segment (that's for 500+ employee enterprises with dedicated network engineers)
• Custom identity-aware proxy infrastructure (Google built this with hundreds of engineers; you're not rebuilding it)
• Zero-trust network access (ZTNA) replacing a VPN before you've addressed identity and device management
• A product you buy that "implements zero trust" without changing your access policies

The highest-leverage zero trust work for a 50-person company happens in identity and device management — not in network architecture. Get identity right first. Add network controls after.

---

5-Step Implementation for a 50-Person Company

Step 1: Consolidate Identity (Weeks 1–3)

Zero trust starts with knowing who is accessing your systems. If users authenticate differently to different applications — some with username/password, some with Google SSO, some with shared credentials — you cannot verify identity consistently or revoke access completely when someone leaves.

What to do:

Deploy a cloud identity provider and connect all your applications to it. For most SMBs, this is one of:

• Okta: The enterprise standard. $6–8/user/month for the features that matter. Connects to 7,000+ applications. Worth the cost if you have more than 15 users.
• Google Workspace Identity: If you're already on Google Workspace, you have this. Activate SSO for your SaaS applications.
• Microsoft Azure AD (Entra ID): If you're on Microsoft 365, Azure AD is included. The free tier covers SSO for up to 500 applications.
• JumpCloud: A strong option for SMBs — directory, SSO, and device management in one platform. $11/user/month for the full stack. Good choice if you want to consolidate.

Enforce MFA on everything. No exceptions. Not "encourage" — require. Users who don't enroll in MFA within 30 days of policy implementation lose access to SSO-protected applications.

MFA method matters: authenticator apps (Google Authenticator, Authy, Okta Verify) are acceptable. Hardware keys (YubiKey) are better for admin accounts. SMS-based MFA is better than nothing but vulnerable to SIM-swapping attacks — don't rely on it for admin access.

Catalog your applications. Make a list of every application that handles company data. Connect them to SSO. Eliminate shared credentials. If an application doesn't support SSO, that's a security decision to note — either accept the risk, require personal credentials, or replace the application.

Success metric: Every employee authenticates to every company application through your identity provider. No shared credentials. MFA enforced for everyone.

---

Step 2: Implement Device Management (Weeks 2–4)

Identity tells you who is accessing your systems. Device management tells you whether the device they're using is trustworthy.

A managed device is one that:

• Has your security policies applied (disk encryption, screen lock timeout, software update enforcement)
• Has your endpoint detection and response (EDR) software installed
• Is enrolled in your MDM so you can wipe it if it's lost or stolen
• Is known to your identity provider so you can require device compliance as a condition of access

An unmanaged device — a personal laptop, a family shared computer — is a risk. You have no visibility into what's on it, whether it's patched, or whether it's been compromised.

What to deploy:

MDM (Mobile Device Management):

• Jamf: The standard for Mac-heavy teams. $4–6/device/month. If your team uses Macs, start here.
• Microsoft Intune: Included with Microsoft 365 Business Premium ($22/user/month). Manages Windows, Mac, iOS, and Android. Good if you're already on Microsoft.
• Kandji: Modern Mac MDM with strong compliance policy automation. ~$6/device/month.

Minimum device policies to enforce:

• Disk encryption required (FileVault on Mac, BitLocker on Windows)
• Screen lock after 5 minutes of inactivity
• Automatic OS updates enabled (or enforced with 30-day maximum delay)
• Company applications only from managed app catalog (optional but useful)
• Remote wipe capability for lost/stolen devices

Endpoint detection:

• CrowdStrike Falcon Go: $59.99/device/year. Industry standard for detection quality.
• SentinelOne Singularity Core: Comparable detection quality, competitive pricing.
• Microsoft Defender for Business: Included with Microsoft 365 Business Premium. Adequate for most SMBs.

Connect device compliance to access. This is where zero trust gets real: configure your identity provider to require device compliance as a condition of access. An employee trying to log in from an unmanaged personal laptop gets blocked — they authenticate with their identity, but the device isn't enrolled in MDM and doesn't meet compliance requirements, so access is denied.

In Okta, this is an Adaptive MFA policy. In Azure AD, this is a Conditional Access policy. In Google Workspace, this is Context-Aware Access.

Success metric: 100% of company devices enrolled in MDM. Device compliance enforced for access to company applications. EDR deployed on all devices.

---

Step 3: Apply Least Privilege Access (Weeks 3–6)

Most companies accumulate access debt. A developer who was granted admin access to a production database two years ago to debug an incident still has that access. A former contractor's account wasn't fully deprovisioned. Marketing has read access to engineering repositories "just in case."

Least privilege means giving people the minimum access required to do their job — no more, no less.

The access audit:

Start with your highest-risk systems: cloud infrastructure (AWS/GCP/Azure IAM), your primary database, source code repositories, customer data systems. For each:

1. List every account with access
2. Identify what access level they have (admin, read/write, read-only)
3. Determine what access level they actually need for their current role
4. Remove or downgrade excess access

This exercise regularly surfaces: former employees whose accounts weren't fully deprovisioned, service accounts with human-level access, broad role assignments granted for convenience that were never narrowed, shared credentials for services that should have individual accounts.

Privileged Access Management (PAM) for admin accounts:

Admin accounts — cloud IAM admin, database admin, domain admin — should not be used for day-to-day work. A security engineer should not be browsing Slack with the same account they use to manage cloud IAM. The risk: if their browser session is hijacked, the attacker has admin access.

The pattern for admin accounts:

• Create a separate admin account (e.g., firstname.lastname-admin@company.com)
• MFA required, hardware key preferred
• Admin account is not used for email or browsing
• Privileged access sessions are logged and time-limited

For cloud infrastructure specifically: use AWS IAM roles with time-limited sessions rather than persistent IAM user credentials. Require MFA for role assumption on sensitive roles.

Just-in-time (JIT) access:

Rather than granting persistent access to sensitive systems, require users to request access when they need it and automatically revoke it after a defined period. Tools that enable this at SMB scale:

• AWS IAM Identity Center (formerly AWS SSO): Time-limited role assignments, request/approval workflow. Free.
• Teleport: Open-source access proxy for SSH, Kubernetes, databases. Request → approve → access → automatic expiry.
• Okta Access Requests (with Okta Privileged Access): Workflow for requesting access to sensitive applications with automatic expiry.

JIT access for truly sensitive systems — production database, cloud admin console — is a meaningful security improvement that eliminates a large category of insider threat and credential theft risk.

Success metric: Access review completed for all high-risk systems. No unnecessary admin accounts. JIT access implemented for cloud and database admin access.

---

Step 4: Implement Network Segmentation (Weeks 4–8)

Network segmentation limits the blast radius of a breach. If an attacker compromises a device or account, network segmentation determines what they can reach from that foothold.

For a 50-person company, full microsegmentation (where every service can only talk to the specific services it needs) is engineering overhead that's out of proportion to your risk. What's practical and valuable:

Segment your cloud environments:

• Production, staging, and development should be in separate accounts/projects/VPCs with no direct access between them
• Production access requires explicit role assumption — no developer should be able to access production with their development environment credentials
• Database access from production should come only from application servers in defined security groups, not from any machine with valid credentials

Implement cloud-native network controls:

• AWS Security Groups / GCP Firewall Rules / Azure NSGs: Define explicit allow rules for service-to-service communication. Default deny everything not explicitly permitted.
• VPC Flow Logs: Log all network traffic. If something unexpected is communicating with your database or exfiltrating data, you want to know.

Remote access:

Traditional VPNs give authenticated users access to the full internal network. If you still run a VPN for remote access to on-premises resources, consider whether the access it grants is too broad.

VPN replacement tools worth evaluating at SMB scale:

• Tailscale: Peer-to-peer encrypted mesh network. $6–12/user/month. Engineers connect to specific services, not to a broad network. Easy to deploy, well-regarded by small engineering teams.
• Cloudflare Access (Zero Trust): Identity-aware proxy for web applications. Free for up to 50 users. Users authenticate with your identity provider to access internal applications — no VPN required.

For most 50-person companies, Cloudflare Access (free) for web application access combined with Tailscale for SSH/database access is a strong replacement for a traditional VPN.

Success metric: Production, staging, and development environments are separated. Database access is restricted to application servers only. Remote access requires identity verification, not just VPN credentials.

---

Step 5: Continuous Monitoring and Response (Ongoing from Week 2)

Zero trust is not a state you achieve — it's a continuous process of verifying that your controls are working and responding when they're not.

What to monitor:

• Failed authentication attempts: A spike in failed logins for a specific user or from an unusual location is an early indicator of credential stuffing or a compromised credential.
• New device or location logins: First-time access from a new device or country should trigger a re-authentication challenge or alert.
• Admin access usage: Log every time an admin account is used. Admin access should be rare and purposeful.
• Cloud configuration changes: Changes to security groups, IAM policies, or encryption settings in production should be logged and alertable.
• Data access anomalies: Bulk exports from your database or file storage at unusual hours.

What to use:

At 50 people without a dedicated security team, you don't need a full SIEM. You need:

• Cloud-native threat detection: AWS GuardDuty ($50–200/month depending on scale), GCP Security Command Center, or Microsoft Defender for Cloud. These analyze cloud logs automatically and surface anomalies without requiring a security analyst to write detection rules.
• Identity provider alerts: Configure your identity provider to alert on suspicious sign-ins, disabled MFA, and new admin grants.
• EDR alerting: Your endpoint detection tool should send alerts for anything requiring human review. Make sure someone is receiving and acting on those alerts.

Incident response:

Zero trust reduces the probability of a significant breach. It doesn't eliminate it. Have a documented (and tested) incident response procedure that covers: who gets called, who has authority to revoke access across systems, how you contain a compromised account, and how you communicate with customers if data is affected.

The procedure doesn't need to be long — a one-page playbook for the three most likely scenarios (compromised credential, compromised device, phishing attack leading to data access) is more valuable than a 40-page policy no one has read.

---

Tools That Work at SMB Scale

This is the practical short list — tools that have strong SMB adoption, reasonable pricing, and don't require a dedicated security team to operate.

Category	Tool	Price	Best For
Identity Provider	Okta	$6–8/user/mo	Teams that want best-in-class SSO
Identity Provider	JumpCloud	$11/user/mo	Teams wanting SSO + MDM combined
Identity Provider	Azure AD (Entra)	Included w/ M365	Microsoft shops
MDM	Jamf	$4–6/device/mo	Mac-heavy teams
MDM	Kandji	~$6/device/mo	Mac teams wanting strong automation
MDM	Intune	Included w/ M365 BP	Cross-platform Windows+Mac
Endpoint Detection	CrowdStrike Falcon Go	$60/device/yr	Best detection quality, any size
Endpoint Detection	MS Defender for Business	Included w/ M365 BP	Microsoft shops, adequate for most
Remote Access	Tailscale	$6/user/mo	Dev/engineering access to infrastructure
Remote Access	Cloudflare Access	Free under 50 users	Web application access
Cloud Threat Detection	AWS GuardDuty	~$50–200/mo	AWS environments
Cloud Threat Detection	MS Defender for Cloud	Included w/ M365	Azure environments
PAM / JIT Access	Teleport	Open source / $5+/user	SSH, K8s, database access

---

What to Skip at the 50-Person Stage

Full microsegmentation: Engineering-intensive, high operational overhead, appropriate for 500+ employees with dedicated network security staff. Get identity and device management right first.

On-premises hardware security appliances: If you're cloud-native, dedicated hardware firewalls and network intrusion detection hardware add cost and complexity without proportionate security benefit.

Custom SIEM with detection engineering: Building custom detection rules in Splunk or Elastic SIEM requires a security analyst to write, tune, and maintain them. Cloud-native threat detection (GuardDuty, Defender for Cloud) delivers 80% of the value with 5% of the operational overhead.

Zero Trust Network Access (ZTNA) platforms: Zscaler, Palo Alto Prisma Access — enterprise ZTNA platforms with enterprise pricing. Tailscale and Cloudflare Access deliver the practical SMB implementation at a fraction of the cost.

Separate identity governance and administration (IGA) platform: SailPoint, Saviynt — appropriate for 500+ employee organizations with complex joiner/mover/leaver processes. At 50 people, your identity provider's access review features handle this.

---

Measuring Progress

Zero trust implementation at SMB scale can be measured against five questions:

1. Identity: Does every user authenticate to every company application through your identity provider with MFA enforced?
2. Devices: Are all company devices enrolled in MDM with compliance policies enforced, and is device compliance required for access?
3. Least privilege: Has an access review been completed for all high-risk systems in the past 90 days? Is JIT access implemented for admin functions?
4. Network: Are production, staging, and development environments isolated? Is remote access identity-aware rather than perimeter-based?
5. Monitoring: Are you receiving and acting on alerts from cloud threat detection and identity provider anomaly detection?

If you can answer yes to all five, you have implemented zero trust at the level that's appropriate and practical for a 50-person company.

If you're working through this and want to understand where your current security posture stands, the Zero Trust Security service page covers what a managed implementation looks like — including assessment, implementation, and ongoing monitoring. Or book a free security assessment for an evaluation of your current controls against these five criteria and a prioritized remediation plan.