How to Implement Zero Trust in Your Company

A colleague leaves, but their old email account, VPN access, and password for a supplier portal remain active for weeks. Meanwhile, an external accountant remotely accesses billing, the warehouse manager works from their own spreadsheet, and multiple people use a shared admin account for the production system. When considering how to implement zero trust, it's not just about deciding on IT security tools. The question is whether the company knows exactly who, from what device, for what business reason, and for how long has access to critical information and systems.

The basic principle of the zero trust approach is simple: do not automatically trust any user, device, or network just because it originates from the corporate office or internal network. Every access must be identified, verified, and limited to the specific task. In practice, this does not mean making every employee's job harder. When well-planned, it eliminates unnecessary, overly broad permissions and creates clearer operational responsibilities.

Implementing zero trust does not start with the firewall

Many organizations' first reaction is to acquire a new security product. This is understandable but often the wrong order. If it's unclear which system supports what business process, who owns the system, and who really needs access, then the new technology just adds to the existing disorder.

It's worth starting from daily operations. Let's examine a complete process, such as the journey of an online shop order from payment through invoicing and picking to the delivery note. In which systems does the data appear? Who can modify the order? Who can see customer data, prices, or stock information? Where are shared accounts, shared passwords, or Excel files used that former employees can still access?

This exploration is often uncomfortable but yields valuable results. It's not uncommon for a financial employee to have full inventory management rights because they replaced the warehouse manager years ago. Or an external developer can access multiple business systems because no one documented what access is needed for which integration. These are not necessarily human errors. Rather, they indicate that growth outpaced the maintenance of operational rules.

What are we protecting, and why?

Zero trust is not applied with the same rigor to every system. A public product catalog and an HR system containing payroll data do not represent the same risk. At the start of implementation, it's advisable to identify the business resources whose loss, modification, or unauthorized access would cause real operational problems.

These may include financial systems, ERP, production data, customer and supplier databases, webshop administration, warehouse systems, management reports, as well as backups and infrastructure administration. Special attention should be given to systems that rely on the knowledge of a single person or a single technical account.

Prioritization should not be determined solely from a data protection perspective. In a production environment, for example, an overly aggressive access rule can cause downtime or dangerous delays. In a warehouse, the quick use of terminals during shift changes may require a different solution than a financial manager logging in from home. The goal is not maximum obstruction but proportional, justifiable, and business-effective protection.

How to gradually implement zero trust?

A good implementation is not a one-time project but a guided transition. First, identities and permissions need to be organized, then device management, network restrictions, and continuous monitoring can be safely built on this.

1. Be clear about who is who

Start with a complete inventory of user accounts. Not only corporate email addresses should be reviewed, but also accounts in ERP, CRM, webshop, cloud, warehouse, production, and billing systems. Service accounts, technical integrations and external partners' accesses require special attention, as they are often omitted from onboarding and offboarding processes.

Every account should have a designated business owner. It's not the IT department that decides if a purchaser needs access to the contract archive, but the owner of the process. IT's task is to implement this decision securely, documented, and verifiably.

Shared accounts should be phased out if possible. If this cannot be resolved in the short term due to an operational device or old application, at least its use, password management, and responsibility should be strictly regulated. A shared account seems quick, but after an event, it's impossible to determine who made changes.

2. The necessary minimum should be the default

The principle of least privilege means everyone only has access to what is needed for their current job. This does not mean that every request requires separate permission. Well-designed roles actually reduce daily administration.

For example, a customer service representative may need access to order status and shipping address but not necessarily the full financial accounting. An external maintenance worker may have time-limited access to a server but does not need constant VPN access to the entire network. Viewing management reports can be separated from editing them or modifying the underlying data.

Permissions should be tied to job roles and business roles, not a long list of personalized exceptions. Exceptions are sometimes unavoidable but become a constant risk without an expiration date, justification, and regular review.

3. Strengthen login but don't slow down work

Multi-factor authentication is one of the quickest and most impactful measures to implement, especially for email, remote access, admin accounts, and cloud services. However, it is not a zero trust strategy by itself. If a user has overly broad permissions, the second authentication factor only confirms that they indeed logged in.

Usability is a crucial issue here. An authentication app may be suitable for an office worker. In environments with shared workstations, shifts, or warehouse staff working with protective gloves, a different login process is needed. Security cannot be designed without considering real work processes, as employees will seek workarounds.

4. Examine the device and the connection as well

The risk is not the same if someone logs in from a centrally managed, updated corporate laptop or an unknown personal computer. Zero trust therefore considers the device's state: is it encrypted, are updates installed, is necessary protection running, is the device owner known.

This should be introduced gradually. Initially, it may be sufficient if administrative and financial systems are only accessible from managed devices. Later, the rule can be extended to other critical applications. However, for an old, operational-purpose machine or specialized manufacturing equipment, modern device management software may not be installable. In such cases, network isolation, limited access, and stricter supervision may be the right solution.

The network should not be an automatic entry

According to the traditional internal network model, anyone physically inside or connected via VPN can access many systems. Zero trust dismantles this assumption. In the case of a compromised laptop or stolen password, an attacker should not be allowed to move freely within the entire environment.

This typically involves network segmentation, access tied to applications, and reviewing communication between systems. For example, the webshop should only access the ERP data necessary for order processing. A reporting system does not need to write to the production database. A technical account created for an integration should not be usable for interactive login.

When developing detailed rules, understanding system connections is essential. A communication closed too quickly can easily interrupt an invoicing transfer, stock synchronization, or production data collection. Therefore, network protection is not an isolated IT task: it requires a joint examination of business processes and technical dependencies.

Measure, monitor, improve

The state of zero trust is constantly changing. New employees, new suppliers, acquisitions, system implementations, and temporary projects all create new accesses. Control works when it is part of the onboarding, role-changing, and offboarding process, not just an annual spreadsheet check.

It's worth regularly examining administrative permissions, long-unused accounts, expired external accesses, and failed login attempts. Logging is not valuable in itself. It is useful when a deviation can determine what happened, who is responsible for the system, and what action is needed.

One of the best signs of success is not that more security alerts appear. Instead, a new colleague's onboarding is faster and more traceable, a departing employee's accesses can be securely closed, an external partner's permissions do not remain open, and a business process does not depend on a single shared password.

Zero trust becomes an operational advantage when the company does not rely on memory to manage who has access to what. Accesses become as much a part of the organized business process as approving an order, transferring a production batch, or issuing an invoice.