Why 'trust but verify' isn't good enough anymore

01.The old model and how it worked

In the perimeter model, a company had an office, a network and a firewall. Anyone inside the firewall was assumed to be an employee on a company machine. Controls focused on the edge. If you could get past the front door, you had a lot of freedom.

That made sense when staff sat in one building and applications ran in one data centre. The edge was clear and the number of entry points was small.

02.What changed

Three things broke the old model.

• Remote work. People work from home, cafes and client sites. The "inside" now includes home networks you do not control.
• Cloud. Applications and data live in services outside your data centre. The firewall is not between users and these apps.
• Stolen credentials. Attackers log in, rather than break in. A phished password or a stolen session can look like a normal user.

Together these made the perimeter unreliable. The front door is open in many places, and the person walking through it may not be who the badge says.

03.What attackers do once inside

Once an attacker gets inside a trusted network, they move freely. A typical sequence looks like this.

• Gain a foothold. A phishing email or a reused password gives access to one account or machine.
• Look around. The attacker maps what the account can reach: file shares, servers, admin tools.
• Move sideways. They use the access, or steal more credentials, to reach other systems. This is called lateral movement.
• Escalate. They look for administrator rights or accounts that open the most valuable systems.
• Act. They copy data, install ransomware or sit quietly and watch.

The tragedy of the trusted network is step 3. If every internal door is open, one weak account becomes the key to many systems. The initial break-in may be small. The damage depends on how far the attacker can travel.

04.From "trust but verify" to "verify, then limit"

The shift is from occasional checks to continuous verification, and from broad access to limited access. Two practices matter most.

Continuous verification. Do not check once at login and then forget. Look at signals during the session: device health, location, behaviour and the sensitivity of what is being asked for. If risk rises, ask for another factor or end the session.

Limited access. Give each user and system only what the job needs. If a stolen login reaches little, a successful phish becomes an irritation rather than a crisis. Segment the network so that systems cannot talk to each other without a reason.

Neither practice requires you to distrust your staff. They simply reduce the harm that any single failure can cause.

05.How to test whether you have the problem

You can find out with simple questions.

• If one employee account were stolen today, which systems could the attacker reach?
• Can a laptop on the guest Wi-Fi reach internal servers?
• How many people can reach your most sensitive systems, and do they all need to?
• Would you notice if an account downloaded far more data than usual?

An internal attack-path exercise, carried out by your team or a trusted partner, gives concrete answers. The number of paths from an ordinary user to a sensitive system is a measure you can reduce over time.

06.An example from the inside

Imagine a mid-sized company where a contractor's laptop is infected after a fake invoice email. The malware captures the contractor's login. In the old model, the attacker connects through the VPN, sees the shared drives, finds a script with an embedded admin password, and takes over a server. The first alert comes weeks later, when files are encrypted.

In a model that verifies continuously, the same login meets several barriers. The sign-in comes from an unmanaged device, so it is refused or limited. If it gets through, it reaches only the contractor's two applications. A request to a file server it has never used raises a risk signal. The security team gets an alert within minutes. The attack is the same. The outcome is not.

07.The role of logging

Limited access works only if you can see what happens. Log sign-ins, policy decisions and access to sensitive systems, and send them to a place where someone looks. Start with a short list of alerts that matter: impossible travel, repeated failed logins, new admin accounts, and large downloads. Tune them for a few weeks to cut noise. An alert that fires fifty times a day teaches people to ignore it.

08.Making the case internally

Leaders often ask whether the change is worth it. Frame it around impact, not fear. Ask: if one account were stolen, how much could be reached? Then show the plan to reduce that number step by step. Share early results, such as apps removed from the VPN or fewer reachable systems per user, so support grows as progress becomes visible.

09.Privileged accounts deserve extra care

Administrator accounts are the prize. An attacker with admin rights can switch off protections and reach almost anything. Treat these accounts differently. Use separate admin identities that are never used for email or browsing. Require the strongest sign-in method. Grant elevated rights only for the time a task needs, and record each use. Review the list of admins every quarter. Reducing the number of standing administrators is one of the cheapest and most effective steps in the whole programme.

10.Common mistakes

• Relying on the VPN as a security control. It is a connection method, not an access policy.
• Granting access "just in case". Permissions pile up and are rarely removed.
• Checking only at login. Sessions can be hijacked after sign-in.
• No logging or nobody looking. Data without review does not catch anything.
• Switching on strict rules overnight. Use monitor mode, learn and then enforce.

11.Third parties and service accounts

Two groups are often forgotten. Contractors and suppliers should get access to named applications only, for a set period, with an owner who confirms they still need it. Service accounts used by scripts and integrations should have their own limited rights, strong secrets that are rotated, and an owner. Old service accounts with broad rights are a favourite target, because nobody notices when they are used.

12.What to do next

• Run the "stolen account" thought exercise for your own company.
• Enable MFA on all accounts and remove weak methods where possible.
• Cut standing access to sensitive systems and review it on a schedule.
• Segment your most valuable systems from the general network.
• Make sure logs reach someone who will read them.

13.Closing

Old trust was based on location. New trust has to be based on identity, device and context, checked continuously and limited by design. A stolen login should reach little and be noticed fast. If you want help moving from a perimeter mindset to a practical zero-trust plan, Brandsmashers can assess where you are and suggest a phased route.