Stage 1: Map Your Assets First, Then Talk About Identity Governance

Zero trust does not begin with buying appliances and installing software. It begins with getting a clear, complete answer to the question of who you are. I have seen far too many companies rush into zero trust without even being able to say how many servers or how many business accounts they have — and end up wasting their budget.

The first task is an asset inventory. That means not only servers and PCs, but also the accounts across every business system — some legacy systems no longer even have an owner, yet their accounts are still active. These “ghost accounts” are the single biggest security risk. Once the inventory is complete, build a device fingerprint database that records each endpoint’s MAC address, operating system version, and whether EDR is installed. Only then can you move on to genuine identity recognition.

Recognition must be followed by authentication. Traditional usernames and passwords are too weak, so MFA is a must. The policy design for multi-factor authentication deserves careful thought: use hardware security keys or mobile tokens for core systems, while TOTP one-time codes are sufficient for ordinary office systems. I recommend starting with VPN and email, where resistance is lowest and employees accept it most readily. Do not spring it on people: send notice two weeks in advance and make sure the IT department has on-site support ready.

Stage 2: Authorization Must Shift from “Wide Open” to “On Demand”

Authentication answers “are you who you claim to be”; authorization answers “what are you allowed to do.” At many companies the reality is that once you are on the internal network, everything is open — OA, finance, and R&D environments are all free to roam. In an era of blurred perimeters, that model is extremely dangerous.

Zero trust authorizes on the principle of least privilege. How does that work in practice? First, classify business systems by sensitivity: R&D code repositories and finance systems are high sensitivity, OA and email are medium, and the internal wiki is low. High-sensitivity systems are opened only to users who have passed MFA and whose devices are compliant; medium-sensitivity systems can be released based on department and job level; low-sensitivity systems can be somewhat looser, but must still be logged.

The policy engine is the core of this mechanism. sTrust’s policy engine supports dynamic evaluation based on user, device, location, and time — not a black-and-white binary decision. If an employee simultaneously meets all three conditions — “normal working hours,” “company device,” and “Beijing IP range” — access can be granted directly. But if that same person signs in from a personal laptop in another city, the system triggers a second authentication step or downgrades access. That kind of flexibility is something a traditional VPN cannot deliver.

Authorization must also account for time limits. A one-time grant is not a permanent grant. In our customer proposals we recommend: three-month validity for ordinary office permissions, one-month validity for sensitive systems, with automatic review and renewal at expiry. This avoids the classic scenario of permissions that outlive the employee.

Stage 3: Branch Encryption and Continuous Auditing Must Keep Pace

Once headquarters is in order, what about branch offices? Many companies connect their branches and field offices through traditional VPNs, with unencrypted traffic and unmanaged devices — effectively opening another hole outside the headquarters firewall. Branch encryption is one of the most easily overlooked yet critically important parts of a zero trust rollout.

Where a branch has good network conditions, consider deploying a dedicated-line-grade encrypted tunnel that links branch traffic to headquarters under a unified access policy. For small sites with limited IT staff, a cloud proxy approach works better: traffic connects to the nearest POP point, is encrypted on its way to the cloud, and is then forwarded — no need to pile up appliances in the branch equipment room.

Whichever approach you choose, audit logs must be retained in full. One of the core values of zero trust is that every access is recorded. Logs should capture who, when, from which IP, on what device, accessing which resource, and with what result. This data is not only a compliance requirement but also the basis for post-incident tracing. I have seen a company discover after a ransomware attack that the attacker had signed into its OA system three months earlier using a former employee’s account — with complete audit logs at the time, much of the investigation time could have been saved.

Auditing also has to answer the question of how long logs are kept. Enterprise data grows fast, and log storage costs are not trivial. We usually recommend keeping frequently accessed hot data from the past three months on local storage, retaining full logs for seven days for fast query, and moving anything older than three months to archival storage — which can cut costs by more than 60%.

Rollout Pace: Three Stages in Three Months

Many companies want to know how long the transformation takes. In my experience, three months is enough to complete the core work — there is no need to drag it into a six-month or year-long campaign.

1. Month one: identity governance. Complete the asset inventory, device fingerprint collection, and MFA rollout. This month is the dullest and the most important — it sets the baseline quality for everything that follows.
2. Month two: authorization redesign. The policy engine goes live, starting with core systems. This month will surface a large number of legacy issues, so be prepared.
3. Month three: branch encryption and audit completion. Wrap up the branch site work and finish building the logging system. The closing phase often turns up details missed earlier — just fill the gaps promptly.

One small suggestion on pacing: hold a brief review at the end of each stage to check whether targets were met, rather than discovering problems only when everything is done. Beijing moves fast, companies cannot afford to wait, and the longer a project drags on, the more variables creep in.

A zero trust rollout is not a one-off project but an ongoing operation. Going live is only the beginning; policy tuning, log analysis, and threat response are the real day-to-day work. It matters a great deal to choose a partner with sustained service capability — do not judge on product features alone, because response speed after the sale is what really counts.