By Danny Jenkins, ThreatLocker CEO and Co-founder
Many cybersecurity frameworks are built around a flawed concept. It is the idea of placing implicit trust in someone with credentialed access.
The May 2026 data breach involving a government insider in New South Wales and the exposure of AWS credentials in the U.S. are quite different at the surface level. One appears to involve a trusted employee abusing access, while the other appears to be the result of credentials being exposed.
Yet both show the same weakness.
Security teams have long focused on putting the steps in place to determine whether a user is legitimate. For many organisations, once that box was checked, users were given broad access to applications and data. The problem is this identity authentication layer cannot tell you what someone intends to do.
That is an important miss when the human factor remains one of the most common ways breaches begin. Verizon’s 2026 Data Breach Investigations Report found that the human element was involved in roughly 60% of breaches. That includes mistakes, misuse, stolen credentials, and social engineering.
Most breaches do not start with an attacker breaking through a firewall, but with a mistake made by someone already inside the environment. This could be falling for a phishing attack, exposing credentials, or a deliberate misuse of access they were trusted with. The question is not whether those situations will occur. They will. The question is why a single user account can still cause so much damage.
That is where those old security strategies fall short. They are built to identify trusted users, not to limit what happens when trust is misplaced.
Insider threats are inevitable, but the outcome is not.
It is well known that insider threats exist. Most, however, are not malicious. These can include innocuous actions such as an employee opening a phishing email, a contractor installing unauthorised software, or a user sharing credentials to solve a problem quickly. None of these actions require harmful intent, but they can all create the same outcome if the environment allows unnecessary access.
Attackers understand this. Stealing a legitimate account is often easier than finding a software vulnerability, although that is changing thanks to AI. Once an attacker has valid credentials, they too often can move through an environment using the permissions already granted to the user. From the system’s perspective, the activity appears legitimate.
That is the problem with trust by default.
If a finance employee needs access to accounting software, that does not mean they need permission to run any executable file. If a browser is approved, that does not mean it should be able to access sensitive files or launch other applications. If a user can access one system, that does not mean they should be able to move freely across the environment. In Zero Trust, this concept is called least privilege—users, systems, and applications should only have access to the resources they need to perform their function. Nothing more.
Security should not depend on every employee making the right decision every time. It should be designed around the assumption that mistakes will happen, credentials will be stolen, and trusted access can be abused.
Detection comes too late when the damage is already done
Many organisations invest heavily in tools that identify suspicious behaviour. Those tools play an important role because they can detect ransomware activity and pause unusual data transfers.
The problem is that detection happens after an action has already started. If ransomware is encrypting files, the attacker is already inside. If a user is uploading large amounts of sensitive data, information may already be leaving the organisation. Even when security teams respond quickly, they are reacting to activity that was allowed to occur in the first place.
That is why security should focus on preventing harmful actions wherever possible. System access should only happen if it’s been explicitly allowed owing to a specific need. If an application is not approved, it should not run. Applications should only have access to other applications if it is explicitly needed, and access to common threat vectors like PowerShell should be blocked by default.
That is not about distrusting employees. It is about limiting the damage when credentials are stolen, mistakes are made, or access is deliberately misused.
Awareness training is not enough
Employees should be trained to spot phishing emails and report suspicious activity, but relying on humans to never make a mistake is a losing proposition.
Phishing emails and credential theft scams are more targeted and more believable, especially with AI making them easier to create. Even well-trained employees click the wrong link. People make quick decisions under pressure while trying to get their jobs done.
This is why awareness training has to be backed by technical controls. If a user downloads malicious software, it should not be allowed to run. If credentials are stolen, the account should not have access unless the request comes from an approved device. If an approved application is being misused, its actions should be restricted.
Cybersecurity cannot rely on perfect human behaviour. It has to control what users and applications are allowed to do.
What practical Zero Trust looks like
Zero Trust is often described as a philosophy. In practice, it is much simpler: Do not allow something just because it comes from a known user, device, or location.
A practical Zero Trust model starts with default-deny. Access should only be granted when it is explicitly needed, and only from approved devices. Applications should only be allowed to run when they are authorised. Even then, approved applications should be limited in what they can do.
That is where controls such as Zero Trust Network Access (ZTNA), Zero Trust Cloud Access, application allowlisting, and application containment come into play.
If a user attempts to access a system from an unknown device, access should be denied. If an application is not approved, it should not run. If an approved application attempts to access data it does not need, execute unauthorised scripts, or communicate with systems unrelated to its purpose, those actions should be blocked.
Allowlisting controls what is allowed to run. Application containment controls what approved applications can interact with. Together, these controls reduce the opportunities for attackers to abuse legitimate access to move laterally.
More importantly, they limit the blast radius when something goes wrong. A phishing attack becomes less damaging if stolen credentials to a network or cloud resource cannot be used from an unauthorised device. A malicious insider becomes less dangerous if access is limited to what their role requires. A compromised application becomes less useful to an attacker if its actions are restricted.
The lesson from incidents like the New South Wales breach is not that organisations should stop trusting employees. It is that trust should never be the control.
People will make mistakes, some insiders will act maliciously, and credentials will continue to be stolen. We can’t stop that even if training grew exponentially. Organisations must assume those things will happen and build controls that prevent them from becoming major breaches.
