Deny by Default is a security principle where access is blocked unless it is explicitly allowed. Instead of permitting an action and checking whether it should be denied, the system starts with no permissions and grants only the access defined by an authorization rule.
For example, an API using Deny by Default rejects requests to protected endpoints unless a policy explicitly permits the user, service, or role to access them. This approach reduces unintended access when permissions are missing, policies are incomplete, or new resources are added without specific authorization rules.
This is part of a series of articles about Application Control.
In this article:
A Deny by Default policy limits the resources available to users, applications, and attackers. Services, executables, network connections, and permissions remain inaccessible unless a business or technical requirement justifies allowing them.
This reduces the number of paths an attacker can use after compromising an account or endpoint. It also prevents newly installed services or applications from becoming accessible simply because no rule explicitly blocks them.
Application control can use Deny by Default rules to prevent unapproved executables, scripts, libraries, and installers from running. Administrators create allow rules based on properties such as file hashes, digital signatures, publishers, or trusted paths.
This approach provides stronger control than maintaining a list of prohibited applications. Software that does not match an approved rule is blocked automatically, including applications that administrators have not encountered before.
Related content: Read our article about unauthorized software
Traditional blocklists depend on identifying malicious software before it executes. Deny by Default controls instead require software to meet defined trust criteria, regardless of whether it has already been classified as malicious.
As a result, unknown executables, newly delivered malware, and modified tools can be prevented from running when they fall outside the allow policy. Other security controls are still needed because approved applications can contain vulnerabilities or be abused for malicious purposes.
Employees may install or use software without approval when endpoint and access controls permit it. A Deny by Default model restricts applications and services to those explicitly authorized by the organization.
This gives security and IT teams more control over which tools can process company data or connect to internal systems. Exceptions can be reviewed before access is granted, helping organizations identify the software in use and apply appropriate security requirements.
Deny by Default blocks access or execution unless a rule explicitly permits it. Allow by Default does the opposite: actions are permitted unless a rule specifically blocks them. The difference determines how a system handles resources, applications, or requests that have no matching policy.
With Deny by Default, unknown software, new network connections, and unspecified permissions remain blocked until approved. This provides tighter control and reduces exposure caused by missing or incomplete rules. However, administrators must identify legitimate requirements and maintain accurate allow rules.
Allow by Default is easier to deploy because existing applications and workflows continue working unless they are explicitly restricted. The tradeoff is that unknown or newly introduced activity is permitted automatically. Administrators must continually identify unwanted behavior and add rules to block it.
For example, an application control policy using Deny by Default allows only approved executables to run. An Allow by Default policy permits every executable except those on a blocklist. This makes the default policy especially important when dealing with new or previously unidentified software.
A Deny by Default security model starts from a simple rule: anything that has not been explicitly permitted is blocked. Each request, application, process, or connection must satisfy an approved policy before it can proceed. This makes access decisions predictable and reduces the chance that missing rules will create unintended access.
The model can operate at several layers. Organizations can apply it to endpoint execution, network connections, cloud resources, APIs, user permissions, and administrative actions. Multiple enforcement points can work together so that approval at one layer does not automatically provide unrestricted access at another.
Deny by Default policies establish the baseline behavior of the security system. When an action does not match an existing allow rule, the enforcement point rejects it rather than assuming it is safe. Administrators therefore do not need to identify every possible unwanted action in advance.
For example:
This behavior is particularly useful when environments change. A newly deployed service, application, or account does not automatically inherit access simply because administrators have not created a rule to block it.
Allowlisting defines the activities that are permitted within the Deny by Default model. Administrators create rules for approved users, applications, services, devices, destinations, or operations based on actual business requirements.
An allow rule can rely on attributes such as:
Combining several attributes can make rules more precise and reduce the scope of each exception. Allowlisting also requires lifecycle management. Rules should be reviewed when applications are updated, employees change roles, or services are retired. Removing obsolete exceptions prevents the allowlist from gradually becoming broader than necessary.
Application control applies Deny by Default decisions when software attempts to execute. Security controls can evaluate executables, scripts, installers, libraries, and other code before allowing them to run on an endpoint or server.
Approval can be based on a verified property, such as a:
Software that fails to match an approved rule is blocked even when it has not previously been identified as malicious. More advanced controls can also examine process relationships. For example, an organization might allow a web browser to run while preventing it from launching an unauthorized scripting engine or command-line tool. This limits ways in which attackers can misuse otherwise approved applications.
Deny by Default also applies to user and service permissions. Authentication identifies the entity making a request, while authorization determines whether that identity has explicit permission to perform the requested operation.
Permissions can be assigned according to roles, resources, actions, and environmental conditions:
This approach works well with least privilege because unspecified permissions remain unavailable. If an account is compromised, the attacker is limited to the operations that the account was explicitly authorized to perform rather than gaining access to resources without defined restrictions.
Enforcement points for Deny by Default security must evaluate relevant actions whenever they occur, including:
Policies also need to remain synchronized with changes in the environment. Software updates can change signatures or file hashes, employees can move between roles, and new services can require additional connections. These changes may require carefully scoped updates to existing allow rules.
Logging and monitoring provide feedback for maintaining the model. Repeated denials can reveal attempted attacks, unauthorized software, or legitimate activity that was not covered by the policy. Security teams can investigate these events and adjust rules without changing the Deny by Default baseline.
Organizations can create allow rules for applications that users and systems need for legitimate work. Trust can be established using file hashes, digital signatures, software publishers, package identities, trusted paths, or combinations of these attributes.
Publisher-based rules are useful for applications that receive frequent updates because correctly signed new versions can remain trusted without requiring a new hash rule for every file. More restrictive rules can be used for sensitive systems where administrators need tighter control over application versions.
Trust should not depend only on whether software is legitimate. An application may be valid but unnecessary for a particular device or user. Limiting approved software to what each system requires reduces the number of programs available for misuse.
When an executable does not match an allow rule, a Deny by Default application control system blocks it. The file does not need to appear on a malware list or be recognized as a known threat before the control takes effect.
This helps address newly created malware, unauthorized utilities, and software downloaded by users without approval. It can also prevent an attacker from introducing custom tools that traditional signature-based detection has never encountered.
Blocked execution events should be logged with information such as the file, user, device, process, and rule involved. Security teams can use these records to distinguish malicious activity from legitimate software that requires an additional policy.
Application control policies can extend beyond .exe files to other forms of executable code. Scripts, installation packages, dynamic libraries, macros, and command-line tools can all provide ways to execute code and therefore need appropriate controls.
For example, allowing a scripting engine without controlling which scripts it can execute may create a path around restrictions on conventional applications. Similar problems can occur when trusted applications load unapproved libraries or installers introduce executable components.
Organizations can define separate rules for these file types and execution mechanisms. The exact controls depend on the operating system and application control technology, so policies should account for every supported method of running code.
Some applications cannot be covered by broad allow rules. Internally developed tools, legacy software, temporary utilities, and applications without reliable digital signatures may require exceptions.
Exceptions should be narrowly defined rather than disabling application control for an entire device or user group. For example, an organization can approve a particular file hash, publisher, application path, or limited set of users instead of permitting all software from an unrestricted location.
Exception management should also include ownership and review. Temporary exceptions can have expiration dates, while permanent exceptions should be reassessed when applications change or are no longer required. This prevents old exceptions from becoming unintended execution paths.
Application control must account for changes to software after it has been approved. If trust is based on properties that an attacker or user can modify, an approved application location could become a way to execute unauthorized code.
Policies can use cryptographic hashes and digital signatures to verify application identity and integrity. File-system permissions can complement these controls by preventing standard users from modifying trusted executables, libraries, scripts, and directories.
Organizations can also restrict who may install or update approved applications. Combining application control with protected installation processes helps ensure that software remains within the conditions under which it was originally trusted.
A Deny by Default model depends on accurate policies and ongoing maintenance. Rules that are too broad weaken the security benefit, while overly restrictive rules can interrupt legitimate work. Organizations should build policies from observed requirements, control exceptions, and regularly verify that existing permissions are still needed.
Start by identifying the applications required for business operations and system administration. The inventory should include desktop software, background services, command-line utilities, scripts, installers, and internally developed applications.
Organizations can then define trust using properties such as:
Publisher rules can simplify management for frequently updated signed software, while hash rules provide tighter control over individual files. Avoid broad rules that trust writable directories or entire groups of applications without a clear requirement. If users can modify files in an allowed location, an attacker may be able to place unauthorized code there and bypass the intended restriction.
Enabling Deny by Default enforcement immediately can block legitimate applications that were missed during policy development. When supported by the application control platform, audit or learning mode can record what would be blocked without preventing execution.
Administrators can use these events to identify:
The collected information can then be used to refine allow policies before enforcement begins. Audit data should be reviewed rather than automatically converted into allow rules. Observed software may include unauthorized applications or malicious activity, so each addition should have a valid operational requirement.
Some legitimate software will not fit standard allow policies. Organizations need a controlled process for requesting exceptions when users, developers, or administrators require an application that would otherwise be blocked.
An exception request should document the:
Security teams can then evaluate how narrowly the exception can be defined and whether another approved application provides the same capability. Temporary exceptions should expire when they are no longer required. Permanent exceptions should have an owner and remain subject to periodic review so that outdated permissions do not accumulate.
Blocked execution events provide useful information about both attacks and policy problems. Monitoring can reveal malware execution attempts, unauthorized administrative tools, shadow IT, and legitimate applications that were omitted from the allow policy.
Logs should contain enough context for investigation, including the:
Centralizing these events makes it easier to identify repeated or widespread activity. Not every blocked event represents malicious behavior. Security teams should distinguish expected policy enforcement from unusual patterns that require investigation, such as repeated attempts to execute unknown files across multiple endpoints.
Application environments change as software is installed, upgraded, replaced, or retired. Allow policies need to change with them. Otherwise, obsolete rules can remain active while new business applications are unnecessarily blocked.
Reviews should identify:
Changes to publishers, signatures, file locations, and application dependencies may also require policy updates. Organizations should test significant policy changes before broad deployment when possible. Combining regular reviews with audit data and blocked-event monitoring helps keep the allow policy restrictive without disrupting required applications.
Airlock Digital helps organizations turn Deny by Default from a security principle into day-to-day practice on their endpoints. The platform enforces strict control over what runs, so only trusted applications, scripts, and processes are allowed to execute, while everything else is blocked. This proactive approach stops unauthorized applications and threats before they execute, reduces the attack surface across every endpoint, and supports operational resilience across both IT and OT environments.
Key capabilities of Airlock Digital:
Learn more about achieving Deny by Default on endpoints with Airlock Digital