Zero Trust Is Not a Product You Install on Friday

A contractor still has VPN access three months after the project ended. Nobody noticed because the account was in a shared group called engineering-external, the group was excluded from MFA during a bad rollout, and the firewall rule says any because someone needed to fix production during an outage.

That is not a weird edge case. That is Tuesday.

Zero trust gets marketed like a clean architectural pattern. In real environments, it is usually a fight against old trust decisions that became invisible. A flat network. A jump box everyone uses. A CI token with admin rights. A service account named after a person who left in 2022. A security exception with no owner and no expiry date.

The useful version of zero trust is much less dramatic than the slide decks. It means every request has to prove who it is, what it is allowed to do, and whether the risk makes sense right now. Then you log enough of that decision to investigate it later.

That is the whole game.

Start with what attackers actually use

Attackers do not care whether your cybersecurity program has a zero trust roadmap. They care whether one password, one token, or one open network path gives them the next foothold.

Most ransomware incidents follow boring mechanics before they become board-level events. Credentials get phished, reused, dumped from a host, pulled from a build log, or stolen from a developer laptop. Then the attacker moves sideways. Then they find data, backups, domain admin, cloud admin, or all of the above.

Zero trust is supposed to make that chain harder. Not impossible. Harder.

If your answer to compromise is still, "Once you are on the VPN, you are inside," you do not have zero trust. You have a moat with a badge reader.

Engineering teams should start by mapping trust paths, not buying tools. Ask simple questions that become uncomfortable fast.

Who can reach production databases from a laptop? Which service accounts can deploy? Which workloads can talk to the metadata service? Which security groups allow east-west traffic because nobody wanted to break something? Which IdP groups grant admin access through three layers of nesting?

Run the commands. Do not debate diagrams.

# AWS: find wide ingress rules
aws ec2 describe-security-groups \
 --query "SecurityGroups[?IpPermissions[?IpRanges[?CidrIp=='0.0.0.0/0']]].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}"

# Kubernetes: see who has cluster-admin
kubectl get clusterrolebindings -o json \
 | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | {name:.metadata.name, subjects:.subjects}'

# Linux: look for passwordless sudo
sudo grep -R "NOPASSWD" /etc/sudoers /etc/sudoers.d 2>/dev/null

Those outputs are often more honest than the policy document.

Identity is the new perimeter, but that phrase hides work

People say identity is the new perimeter because it sounds modern. The engineering version is less tidy: identity is now in your IdP, your cloud IAM, your Kubernetes RBAC, your SaaS admin panels, your CI system, your secrets manager, your VPN replacement, and three old appliances nobody wants to touch.

Zero trust fails when identity is treated as one project owned by one team. It has to be enforced where engineers actually make changes.

For humans, start with MFA that cannot be bypassed through legacy protocols or forgotten exception groups. Use phishing-resistant MFA for administrators where you can. Kill shared accounts. Put privileged access behind time limits. Make group membership reviewable without opening a support ticket and waiting a week.

For machines, stop pretending service accounts are less risky than users. They are usually worse. They do not complain when permissions are excessive, they do not rotate themselves, and they often sit in automation that nobody wants to edit.

A decent service account policy is not poetic:

service_account_rules:
 owner_required: true
 human_login_allowed: false
 credential_rotation_days: 90
 production_access_requires_approval: true
 unused_disable_after_days: 30
 secrets_stored_in: vault_or_cloud_secret_manager

The exact numbers can change. The shape should not. Every non-human identity needs an owner, a purpose, a permission boundary, and an expiry story.

Network segmentation still matters

Some zero trust pitches quietly imply the network no longer matters. That is nonsense. The network matters because compromised systems still need paths to useful targets.

The difference is that segmentation should no longer be your only control. A private subnet is not a security boundary if every workload inside it can talk to every other workload and all of them trust the same metadata endpoint.

In Kubernetes, NetworkPolicies are a good example of practical zero trust. Default allow is comfortable until a compromised pod starts scanning the namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-ingress
 namespace: payments
spec:
 podSelector: {}
 policyTypes:
 - Ingress

That policy does not solve security. It changes the default from "sure" to "prove it." Then you add explicit allow rules for the traffic that should exist.

Cloud security groups, NACLs, private endpoints, egress controls, service mesh policy, and host firewalls all have a role. The mistake is using any one of them as a religious answer. Use the control closest to the risk, then test that it works.

This is where a pentest earns its keep. Not a checkbox pentest that produces screenshots of missing headers. A useful pentest tries to move through the same paths an attacker would use. Can a low-privilege cloud key read secrets? Can a compromised pod reach the database? Can a developer token push to production? Can an internal phishing hit become admin access?

If the test cannot answer those questions, it is not testing your zero trust assumptions.

Logging is part of the control, not paperwork

A zero trust decision you cannot see later is only half a decision.

Security operations teams need evidence. Your SOC, whether internal or provided by a partner, cannot detect what your systems never emit. Incident response gets ugly when the first two days are spent discovering which logs exist, where they live, and whether they cover the time window that matters.

At minimum, the following events should be easy to query across your important environments:

identity: login success, login failure, MFA change, group change, admin grant
cloud: IAM policy change, key creation, security group change, public exposure
endpoint: process execution, privilege escalation, persistence, suspicious PowerShell
kubernetes: exec into pod, secret read, role binding change, image deploy
network: denied traffic, unusual egress, new inbound exposure
ci_cd: pipeline change, secret access, production deploy, runner registration

This is not about hoarding logs forever. It is about keeping the right telemetry long enough to investigate a real incident. If ransomware lands on Friday evening and you only have twenty-four hours of useful endpoint data, your Monday is going to be unpleasant.

Detection rules should also match the architecture you actually run. A managed detection tool with no cloud context will miss cloud abuse. A SIEM full of cloud logs but no endpoint visibility will miss credential theft on laptops. A beautiful dashboard nobody tunes is expensive wallpaper.

The developer experience cannot be hostile

Security teams sometimes design zero trust controls as if engineers are the enemy. That backfires. Engineers will route around controls that make normal work painful, especially during an incident.

The goal is not friction everywhere. The goal is the right friction at the right moment.

Reading logs from production should not require the same ceremony as changing a production IAM role. Deploying to a test namespace should not feel like requesting access to payroll data. Break-glass access should exist, but it should be loud, time-boxed, and reviewed.

Good zero trust design makes the secure path the normal path. SSO works. CLI access works. Short-lived credentials are easy to request. Local development has a sane pattern. Emergency access is documented before the outage.

Bad zero trust design creates a maze, then blames engineers for carrying bolt cutters.

Hardening beats slogans

If you want to make zero trust real, pick one production service and trace the full path.

Start at the developer laptop. Follow the identity into the IdP. Follow deployment through CI. Follow the workload into runtime. Follow its secrets. Follow its network access. Follow its logs. Follow the backup and restore path. Then ask what happens if one step is compromised.

You will find gaps. That is the point.

Maybe the CI runner can assume a role that can modify IAM. Maybe the pod can read all secrets in the namespace. Maybe production database access is controlled by a security group but not by database roles. Maybe backups are reachable from the same admin identity used everywhere else. Maybe the incident response runbook assumes the IdP is available, which is optimistic during an identity compromise.

Fix those one at a time. Tighten IAM. Add conditional access. Reduce standing privilege. Add network deny defaults. Move secrets out of environment variables where practical. Add detection for the control changes attackers make before they make noise.

Zero trust is not a migration you finish. It is a pressure you keep applying to lazy trust.

If you only do one thing this week

Pick your most important production system and answer this question in writing: if one engineer laptop is compromised, what can the attacker reach without triggering a high-confidence alert?

Do not answer from memory. Prove it from IAM, network policy, CI permissions, endpoint controls, and logs.

That exercise will tell you more about your zero trust posture than a vendor maturity chart. It will also give engineering, security, and operations a shared map for what to fix next.

Zero trust is not magic. It is disciplined distrust, applied to the places where compromise usually turns into damage.

If this is on your plate, TecLeads does exactly this as part of our Cybersecurity work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.