Category: Authorization Concepts

Deny by Default

Also known as: Default Deny, Global Default Deny

Simply put

Deny by default is a security approach where access or traffic is blocked unless it has been explicitly permitted. Rather than allowing everything and then blocking specific exceptions, the system refuses anything that has not been expressly authorized. This reduces the chance that unintended or unforeseen access slips through.

Formal definition

Deny by default is an access control posture in which the default outcome of an authorization or filtering decision is denial, so that only requests, traffic, or actions expressly permitted by policy are allowed. In the network filtering context defined by NIST SP 800-41 Rev. 1, it means blocking all inbound and outbound traffic that has not been explicitly permitted by firewall policy. In network policy platforms such as Calico, a global default deny policy denies ingress and egress for workloads that lack an explicit allow policy (or that carry incorrect policy). The principle generalizes to authorization enforcement broadly: absent a matching permit rule, the decision resolves to deny. Note that this evidence packet addresses the concept primarily in network traffic filtering terms; its application to identity- and attribute-based authorization decisions (for example as a policy decision point default) is an extension not detailed in these sources.

Why it matters

Deny by default inverts the risk model of access control. In a permissive posture where everything is allowed except explicitly blocked exceptions, any gap in the exception list becomes an open door, and gaps are inevitable as systems grow, policies drift, and new services appear that no one remembered to restrict. Under a deny-by-default posture, the failure mode is reversed: an overlooked service or an unrecognized request is denied rather than silently permitted, so misconfigurations tend to break functionality (which gets noticed and fixed) rather than quietly expand the attack surface.

This principle is foundational to defensible network filtering. As reflected in NIST SP 800-41 Rev. 1, a firewall policy that blocks all inbound and outbound traffic not expressly permitted forces every allowed flow to be a deliberate, documented decision. The same logic underpins modern workload segmentation platforms: in Calico, for example, a global default deny policy ensures that pods without an explicit allow policy, or pods carrying incorrect policy, are not permitted to send or receive traffic, closing the window where an unlabeled or misconfigured workload would otherwise communicate freely.

The trade-off is operational rigor. Deny by default requires that legitimate access be enumerated and maintained; incomplete policy will block intended traffic. This is generally the desired failure direction from a security standpoint, but it demands disciplined policy management and testing so that necessary flows are captured before enforcement is turned on. The evidence here addresses the principle primarily in network traffic filtering terms; extending it to identity- and attribute-based authorization decisions is a natural generalization but is not detailed in these sources.

Who it's relevant to

Network and Firewall Administrators

Those configuring perimeter and internal firewalls apply deny by default directly: following NIST SP 800-41 Rev. 1 guidance, they block all traffic not expressly permitted and enumerate allowed flows as explicit rules. This requires careful documentation of legitimate traffic so that necessary connections are not inadvertently blocked when enforcement is active.

Platform and Kubernetes Engineers

Teams operating containerized workloads use global default deny policies, for example in Calico, to ensure pods without an explicit allow policy, or with incorrect policy, cannot send or receive traffic. They must ensure workloads carry correct network policy before or alongside enabling default deny to avoid disrupting intended communication.

Security Architects

Architects choosing between permissive and restrictive baselines rely on deny by default to make the safe failure mode the default: unenumerated or misconfigured access is blocked rather than silently allowed. They should account for the operational burden of maintaining an accurate permit list and, when extending the principle beyond network filtering to authorization decisions, recognize that such an extension is not covered by the network-focused sources here.

Inside Deny by Default

Default-deny posture

The foundational principle that any access request not explicitly permitted by policy is denied. In most deployments this is the baseline behavior of a policy decision point (PDP), which returns a deny (or 'not applicable' treated as deny) whenever no matching permit rule is found.

Explicit allow rules

The affirmative policy statements that grant access. Under deny by default, access is only possible when a subject, resource, and action are matched by an explicit permit, whether expressed through RBAC role grants, ABAC attribute conditions, or PBAC policies, depending on the access control model in use.

Enforcement point (PEP)

The runtime component that intercepts requests and enforces the decision returned by the PDP. A deny-by-default outcome is only meaningful if the PEP actually blocks the request when no permit is returned; misconfigured or fail-open PEPs can undermine the posture.

Fail-closed behavior

The handling of error, timeout, or indeterminate conditions. A strict deny-by-default design typically fails closed, denying access when the PDP is unreachable or a policy evaluation is inconclusive, rather than falling back to permit. Actual behavior depends on configuration.

Relationship to least privilege

Deny by default is a structural mechanism that supports the least-privilege principle, but the two are distinct: least privilege concerns how narrowly grants are scoped, while deny by default concerns what happens in the absence of a grant.

Common questions

Answers to the questions practitioners most commonly ask about Deny by Default.

Is deny by default the same as denying access to authenticated users?

No. Deny by default is an authorization principle, not an authentication one. Authenticating successfully proves who a principal is, but under deny by default that principal still receives no access to a resource unless an explicit grant applies. Identification and authentication happen first; deny by default governs the authorization step that follows, so a fully authenticated user can still be denied when no matching allow rule exists.

Does deny by default mean I have to write an explicit deny rule for everything?

No. Deny by default means the absence of an explicit allow results in denial, so you typically do not author individual deny rules for every case. In most policy engines, the default outcome is denial and you write only the allow (permit) rules; explicit deny rules are usually reserved for carving out exceptions within a broader permit, depending on how the model resolves conflicting rules.

How does deny by default interact with policy combining algorithms at the PDP?

The default decision is what the policy decision point (PDP) returns when no rule matches or when a request is otherwise indeterminate. Combining algorithms such as deny-overrides or first-applicable determine how multiple matching rules are reconciled, but deny by default specifically governs the fallback outcome for the not-applicable or no-match case. In most deployments the PDP is configured so that anything other than an explicit permit resolves to deny.

How should a PEP behave if the PDP is unreachable or returns an error?

Consistent with deny by default, a policy enforcement point (PEP) typically fails closed, denying access when it cannot obtain an authoritative permit decision from the PDP, including timeouts, indeterminate responses, or PIP attribute-retrieval failures. Whether fail-closed is enforced depends on configuration, and some availability-sensitive deployments intentionally choose fail-open for specific paths, which is a trade-off that should be made explicitly rather than by accident.

How does deny by default apply to token validation?

Under deny by default, a request accompanied by a token that cannot be fully validated is treated as unauthorized. In most implementations this means rejecting the request if signature verification fails, required claims (such as audience, issuer, or expiry) are missing or invalid, or scopes do not cover the requested action. A missing or unverifiable token yields denial rather than a permissive fallback, subject to how the validating service is configured.

How does deny by default relate to access reviews and provisioning in IGA?

Deny by default is primarily a runtime enforcement stance, while identity governance and administration (IGA) processes such as provisioning, access certification, and segregation-of-duties checks determine which explicit grants exist in the first place. The two reinforce each other: least-privilege provisioning and periodic access reviews keep the set of standing allow grants minimal, so that the default-deny posture at enforcement time has fewer exceptions to fall back from. They remain distinct concerns and should not be conflated.

Common misconceptions

Deny by default means the system is secure on its own without further configuration.

Deny by default only sets the baseline behavior for unmatched requests. Security still depends on how explicit allow rules are scoped, how the PEP enforces decisions, and whether the system fails closed. Overly broad permit rules can reintroduce excessive access even under a deny-by-default model.

Deny by default and least privilege are the same thing.

They are related but distinct. Deny by default determines the outcome when no explicit permission applies, whereas least privilege governs how tightly individual permissions are scoped. A deployment can be deny-by-default yet still violate least privilege through over-permissive allow rules.

Once deny by default is set at the PDP, enforcement is guaranteed everywhere.

The PDP only renders decisions; enforcement occurs at the PEP. If a PEP is missing, bypassed, or configured to fail open on errors, requests may proceed despite a default-deny policy. Consistent enforcement across all access paths is required for the posture to hold.

Best practices

Configure policy evaluation to treat 'no matching permit' and 'not applicable' outcomes as deny, and verify this behavior in the specific PDP or vendor implementation you deploy.

Ensure enforcement points fail closed on evaluation errors, timeouts, and unreachable PDPs, rather than defaulting to permit.

Pair deny by default with tightly scoped explicit allow rules so the posture also advances least privilege, not just baseline denial.

Test unmatched and edge-case access requests to confirm they are actually denied end to end, including at every PEP that guards a protected resource.

Audit explicit permit rules regularly to detect overly broad grants that could undermine the intended default-deny effect.

Document and review any intentional exceptions or fail-open configurations, since these directly weaken the deny-by-default guarantee.