On September 3, 2026, the NSA released new cyber hygiene best practices focused on defending against AI-enhanced threats. With cybercriminals increasingly using AI tools to boost attacks, the NSA highlighted weak authentication, unpatched systems, and misconfigurations as persistent issues attackers take advantage of.
The latest guide highlights a number of Zero Trust controls as best practices to defend against advanced persistent threats (APT).
One of the best practices recommended is to implement strict application allowlisting.
The goal of the NSA’s Best Practices for Cyber Hygiene is to provide foundational steps for organizations to reduce attacks surfaces and quickly respond to incidents.
The best way to achieve that is to start with a default-deny allowlisting policy.
Blocklisting is not enough to stop unknown threats
450,000 new malicious and potentially unwanted programs are identified each day.
Every organization has applications that are as close as possible to being trusted. They also have applications that are tolerated and, in many cases, those that fly under the radar, remaining completely unknown to IT teams until they surface.
Few would call that an acceptable level of risk, but it is an easy mode to slip into. It stems from users installing free tools to solve a problem, temporary browser extensions slipping into daily use, or legitimate applications carrying flaws nobody has accounted for.
Under a security regime that relies entirely on blocklisting, administrators attempt to manage that risk by stopping bad applications from running.
Even describing the theory of blocklisting highlights its flaw. It means defining the applications, file types, or behaviors that should be blocked, then allowing everything else to run. Blocklisting is useful for off-the-cuff business action because it is essentially friction-free for users, but it struggles when the threat has not yet been identified.
Given the rapidly evolving nature of often AI-driven malware, the growth of zero-day exploits, and the weaponization of legitimate tools, blocklisting leaves too much room for unknown threats to execute, regardless of how comprehensive and well-maintained the underlying list may be.
Why allowlisting is key against AI-driven malware
Allowlisting reverses the control model, following a deny-by-default Zero Trust approach.
Administrators decide what is allowed, and everything outside that list is blocked by default. Applications, scripts, and libraries must be approved before they can execute.
If the software is unknown, unauthorized, or simply unnecessary, it cannot run. In the case of malicious applications, allowlisting means the attack chain can be stopped before it starts.
Blocklisting does not fit neatly with the principles of a Zero Trust environment or any environment that requires a high level of application control.
A new ransomware payload that does not trigger a block can execute freely. Users have free rein to install extensions or run scripts that have not yet caught the attention of IT.
Blocklisting is not chaos by default, but its effectiveness depends on an incredibly noisy and flawed management process.
Allowlisting provides greater visibility for IT teams
Allowlisting makes the process simple once the environment has been cataloged, giving IT teams a clear view of the approved software estate. This is a direct way to prevent shadow IT issues.
If a new tool is needed, users can request access directly from the endpoint, giving IT a chance to review internally, offer an alternative, and understand the potential impact of approving the application in question.
Without the pain of setup and ongoing administration, Allowlisting reveals itself as a governance tool that doubles up as a very effective defense mechanism.
Admins can determine what runs, when, where, and by whom, so Allowlisting is well suited to maintaining a deny-by-default stance that supports regulatory compliance with key governmental frameworks or to satisfying auditors by clearly demonstrating what is allowed and why.
How to implement allowlisting without friction
Some see allowlisting as problematic because of the management precision it requires. Blocklisting is blunt: It swings at known problems. Allowlisting is more precise, and at the outset, that means making difficult decisions and putting clear rules into action.
In older application allowlisting software, allowlists had to be built manually and updated whenever an approved application was updated. Tight control meant more friction, creating the opposite of the blocklisting problem. Rather than being allowed to do too much, users struggled to do anything at all.
ThreatLocker Allowlisting is designed to facilitate the tight control that it demands, removing much of the operational burden. When the ThreatLocker agent is deployed, it can build a picture of its environment by automatically cataloging existing applications and dependencies.
ThreatLocker Allowlisting already recognizes more than 16,000 applications, giving administrators immediate visibility into what is present and offering advice on potential policy decisions in their operating environment, without having to build everything from scratch. Through the ThreatLocker User Store, end-users can install pre-allowed applications as and when they need them, reducing the friction on IT teams.
Control makes all the difference
For endpoint security within the unique environment that every organization presents, the strongest tools are usually the clearest.
Allowlisting allows for all the nuance a business needs but boils application execution down to a binary rule: If it is on the list, it can run; otherwise, it cannot.
Instead of constantly chasing down the bad, organizations get to define what good looks like. If that definition changes, ThreatLocker allows them to modify their stance cleanly and quickly.
In an environment where software can appear silently and attackers can move quickly, that kind of control makes all the difference.
A version of this article originally appeared in Cyber Hero Frontline, Issue 5, from August 2026.
