Zero Trust

Older security was shaped like a single wall. Checks went up at the point where requests entered the corporate network from outside, and requests already inside were trusted. While everyone worked in the office and the servers sat in the office too, inside and outside were physically separated, so the picture matched reality.

Two changes broke that premise. People started working from home and from cafés, and company data moved out into a set of external services. The customer list lives in a sales tool, documents in a document tool, code in a code repository. None of it is inside any wall, so the place called "inside" stopped existing.

Once that happens, the wall model tilts dangerous. Compromise one employee's laptop and requests arriving through that account get treated as internal, wandering across several systems with no further check. Pagedeck found a contractor's access to its code repository still open six months after the engagement ended. Not because the contractor intended anything, but because nothing checked again after the first time they were let in.

Zero trust moves the basis for the decision from location to identity. What gets checked is not where the connection came from but who you are, which device you're on, and whether that permission is still valid — every time.

Count what needs protecting, attach an identity to every person and device, write access conditions per resource, then log every access and recheck on a schedule.

1. Build a list of what you're protecting. The asset inventory has to exist before anything else works. It's the single table of systems and data that need protection, and a system missing from it gets skipped both when conditions are set and when access is reviewed.
2. Consolidate accounts. Ten separately created logins across ten tools means setting conditions ten times, and one of them will be missed. Tie the tools to a single company account and there's one place to check. The consolidation is usually the longest step, because each tool has its own idea of what an account is.
3. Make the identity check strong. Authentication is the procedure for confirming who someone is, and a password alone doesn't cover it. Requiring a second factor such as a phone approval or a security key means a leaked password isn't enough on its own.
4. Write access conditions per resource: who, on which device, in what state. The customer database opens only from company-managed devices, while the document tool opens from any device that clears the second factor. Underneath sits the principle of least privilege, granting no more than is needed, with broad permissions handed out on a fixed expiry.
5. Log the access. Recording who opened what and when gives you somewhere to look when something goes wrong, and picking out access that doesn't match the usual pattern is only possible with that record.
6. Recheck on a schedule. An access review each quarter reclaims permissions nobody needs anymore. Granting a permission is visible because someone asked for it; the moment it stops being needed, nobody sends a notice. A quarterly date is what catches the gap, since a request to open something briefly rarely stays brief.

It fits companies working remotely or hybrid while using several external services. If people connect from home and data is spread across four places, there's nowhere to draw a wall. It also helps companies facing enterprise security reviews. What those questionnaires mostly ask is who can reach what and how you verify it, and this approach holds the answer structurally.

There are four limits. The first is that buying a product doesn't finish the job. Consolidating the identity system comes first, and that work is cleanup rather than tooling. The second is that you can't start without an asset inventory. If a team has been paying for a survey tool on a company card and thousands of customer emails have piled up inside it, finding that is step one. The third is user friction: stack up too many checks and people find a way around them, at which point the rules and the reality diverge. The fourth is that you can't switch everything at once. For a forty-five person company, starting with the systems holding customer data and widening the scope each quarter is the realistic path, and the first quarter usually covers two systems rather than fourteen.

"Connecting from the corporate network isn't enough. We check the account and the device together."

Shutting down the habit of trusting something because of where it came from.

"Before we go zero trust, the accounts have to be consolidated."

Sorting out identity comes before introducing tools.

"Don't treat that server as fine just because it sits inside the network."

Being inside is no longer protection.

Pagedeck changed its approach after the contractor's access sat open for six months. Theo found it by pulling the user list, and the cause was that the repository appeared on no table at all, so nobody had reviewed it.

The following quarter Theo did three things. He inventoried the fourteen tools the company pays for, tied eight of them to a single company account, and set conditions so the code repository and the customer database open only from company-managed devices. External collaborator accounts got a 90-day expiry so they close on their own. At the next quarterly review there were only two permissions left to reclaim.

The most common assumption is that buying a product makes you zero trust, since security vendors use the name as a tagline. But this is a principle about how access decisions get made, and a product is one way of enforcing it. Bolt on the tooling alone and you gain a new dashboard while the old permissions stay exactly where they were. A setup like that can answer the questionnaire and still have a contractor's account open from an engagement that ended two quarters ago.

Reading it as "trust nobody, so work gets harder" is nearly as common, because the name sounds that way. But the checking is done by systems rather than people, so the lived experience often gets simpler instead. Working outside the office used to mean connecting to the network first; judging by identity and device opens only the resources you need, with no such step. What makes it uncomfortable isn't the number of checks but writing conditions two notches stricter than reality, which is the point where people start sharing logins to get work done.