Why I started studying zero trust
I used to think of network security as a wall. The wall had a VPN for employees and a firewall for the internet. Once you were inside, you were trusted. That model worked until attackers learned that the inside is not empty. A single compromised laptop or a stolen VPN credential can move through the whole network.
This post is my personal study note on zero trust and least privilege. I am writing it because the concepts are simple to describe but hard to implement. The notes focus on the practical path: identity, continuous verification, least privilege, segmentation, and migration.
The problem with the old model
The traditional network model trusts the inside. A user who connects to the VPN is inside the perimeter. A service that listens on an internal port is trusted by the other services. The model assumes that the internal network is safe.
The assumption fails when an attacker compromises an internal host. The compromised host becomes a trusted insider. It can scan the network, access services, and move laterally. The firewall does not stop the movement because the traffic stays inside.
The zero trust model removes the assumption. It treats every request as untrusted, regardless of where it comes from. The identity, the device, and the context of the request determine whether access is allowed.
Identity as the new perimeter
The first step is building a reliable identity system. The identity covers users, applications, APIs, and workloads. Each one needs a way to prove who it is.
Users authenticate with passwords, multi-factor authentication, certificates, or biometrics. Applications authenticate with tokens, certificates, or workload identities. APIs authenticate with keys or tokens. The identity system is the foundation of every access decision.
The identity must be centralized enough to enforce consistent policy, but the enforcement should happen at the resource. A central directory that is ignored by the application is not useful.
Continuous verification
Zero trust does not stop at login. It verifies the request at every step. The verification can include the user's identity, the device posture, the location, the risk score, and the behavior.
A device that was healthy at login may be compromised an hour later. A user who normally logs in from one country may suddenly connect from another. The risk context changes, and the access should change with it.
Continuous verification is not about making the user log in constantly. It is about evaluating the context with every request and adjusting the policy when the context changes.
Least privilege
Least privilege is the principle that every identity gets only the permissions it needs. A user who only needs to read reports should not have write access. A service that only needs to call one API should not have access to the whole database.
The implementation starts with a permission matrix. The matrix lists the roles, the resources, and the actions. The policy is built from the matrix, and the default is deny.
The permissions should be short-lived. A temporary credential that expires is less dangerous than a permanent key. The rotation should be automatic, and the access should be reviewed regularly.
Microsegmentation
Microsegmentation is the network layer of zero trust. It divides the network into small segments and controls the traffic between them. A workload in one segment cannot reach a workload in another segment without permission.
The segmentation is enforced by firewalls, policy engines, and network overlays. The policy can be based on the identity of the workload, not just the IP address. This makes the policy portable and easier to manage.
The hardest part is mapping the legitimate traffic. Before I segment a network, I need to know which services talk to each other. A segmentation policy that blocks a legitimate dependency can break the application.
Mutual TLS and service identity
Service-to-service traffic needs its own identity. Mutual TLS, or mTLS, authenticates both sides of the connection. The client proves its identity with a certificate, and the server proves its identity too.
mTLS prevents an attacker from pretending to be a trusted service. If an attacker compromises a workload, the workload cannot impersonate another workload without the certificate. The certificate lifecycle must be managed carefully.
The service mesh or the policy engine can issue and rotate the certificates automatically. The automation is important because manual certificate management does not scale.
The policy engine
The policy engine is the brain of the zero trust architecture. It receives the context of the request and returns a decision. The decision is based on the identity, the device, the resource, and the risk.
The policy should be written as code. The code is reviewed, versioned, and tested like any other software. A policy change that breaks the application can be reverted quickly.
The policy decisions should be logged. The log shows who was allowed, who was denied, and why. The log is essential for auditing and for improving the policy.
Migration strategy
Zero trust cannot be deployed overnight. The migration starts with a pilot, then expands to the high-value resources, and finally covers the rest of the environment.
The pilot should include a small number of applications and a clear success metric. The metric could be the number of denied requests, the time to access, or the number of support tickets. The result of the pilot decides whether the next step is ready.
The migration should run in parallel with the legacy controls. The new policy is tested against the real traffic before the old controls are removed. The parallel run reduces the risk of a service outage.
Measuring the result
The result of a zero trust deployment should be measurable. I look at the number of lateral movement paths, the time to detect a compromised identity, and the number of denied requests. The numbers show whether the architecture is working.
The measurement should be continuous. A policy that was correct at the start may become wrong as the environment changes. The review process should be part of the regular security work.
The report should include the gaps. A zero trust architecture is not complete until the identity, the device, the network, and the policy all work together. The gaps are the roadmap.
Device trust is part of the decision
The identity of the user is not the whole story. The device that makes the request also matters. A laptop with an outdated operating system, a missing patch, or a known malware infection should not get the same access as a fully managed device.
I look at the device inventory and the device health before I design the policy. The inventory tells me which devices are managed, which are personal, and which are shared. The health tells me whether the device meets the minimum security baseline.
The device posture can be checked with an endpoint agent, a network access control system, or a cloud identity provider. The check happens before access is granted and can be repeated during the session. A device that falls below the baseline should lose access or be restricted to a lower level.
The tricky part is balancing security with usability. A user with a personal phone may need to check email, but the phone should not have access to the same internal systems as a managed laptop. The policy should be granular enough to support both.
Application-level policy
Zero trust is often implemented at the network layer, but the application layer matters too. The application should make its own authorization decisions. A network policy that allows the traffic does not protect the application if the application does not check the user.
The application can use tokens, claims, and role checks to enforce the policy. The token should carry the identity, the session, and the context. The application should verify the token and check the permissions before it processes the request.
The application-level policy is important because it is the last line of defense. An attacker who bypasses the network policy still needs to pass the application checks. The checks should be central and consistent, not duplicated in every controller.
I also look for legacy applications that cannot be changed. A legacy application may not understand modern tokens or context. The solution is often an API gateway or a reverse proxy that adds the checks in front of the application.
Identity federation
Most organizations have more than one identity source. They may have an on-premises directory, a cloud directory, and a separate system for contractors. The zero trust policy needs to work across all of them.
Federation connects the identity sources with a common protocol. The user authenticates once, and the identity is shared with the applications that need it. The federation protocol must be configured carefully to avoid token confusion and replay.
The federation also creates a single place to manage the user lifecycle. When a user leaves the organization, the access should be revoked everywhere. The revocation should be automatic and fast.
I keep a map of the identity sources and the trust relationships. The map shows which system is authoritative for which user and which application trusts which identity. The map is essential when I troubleshoot an access failure.
Operational challenges
Zero trust changes the way the operations team works. A service that used to be reachable by any internal host now needs a policy. A user who used to connect to everything now needs to request access. The change can create a lot of support tickets.
The operations team needs visibility into the policy and the decisions. A dashboard that shows the allowed and denied requests helps the team respond to problems. The team also needs a way to add temporary access without breaking the security model.
The temporary access should be time-limited and audited. A helpdesk user who grants access should be able to set an expiration time. The request and the approval should be logged.
The culture change is the hardest part. People are used to the idea that the network is safe. Explaining why the model changed is part of the implementation. The explanation should be concrete, with examples of attacks that the old model could not stop.
Lessons from a small pilot
The pilot taught me that the biggest risk is not the technology. It is the policy. A policy that is too strict blocks legitimate work, and a policy that is too open does not protect anything. The pilot team needs a fast way to request access and a clear explanation of the policy. I also learned that the audit log is the most important part of the pilot. Without the log, I cannot tell whether the policy is working or whether I have simply moved the problem to a different layer.
Common mistakes I make
My biggest mistake is starting with the network and ignoring the identity. The identity is the foundation. My second mistake is trying to segment the network before mapping the legitimate traffic. The segmentation breaks the application. My third mistake is treating zero trust as a product instead of a process.
The fourth mistake is forgetting the audit logs. Without the logs, I cannot measure the result or prove that the policy is working. The fifth mistake is trying to do everything at once.
My quick checklist
- Build a centralized identity system for users, applications, and workloads.
- Verify the identity, device, and context with every request.
- Create a least-privilege permission matrix and default to deny.
- Map the legitimate service-to-service traffic before segmentation.
- Use mTLS for service identity.
- Write the policy as code and log every decision.
- Start with a pilot and expand incrementally.
- Measure the result and document the gaps.
What I would do next time
Next time I want to start with a small pilot and a clear metric instead of planning the whole architecture at once. The pilot teaches me what works in the environment. I also want to spend more time on the audit logs, because they are the evidence that the policy is actually working. Zero trust is not a wall. It is a way of deciding who and what can access each resource, one request at a time.