Default deny is an authorization pattern where no traffic is allowed until a policy explicitly permits it. For microservices, it exposes hidden service dependencies and prevents accidental trust between workloads that should only communicate through named, reviewable paths.
Expanded Definition
Default deny is the policy posture that assumes no NHI, workload, or API path is trusted until a control explicitly allows it. In practice, it is the baseline behind Zero Trust Architecture, where access is granted by named policy rather than inherited network position. NIST describes this shift in NIST Cybersecurity Framework 2.0 as a governance and risk reduction discipline, not just a firewall setting.
For microservices, default deny forces each dependency to be intentional: service A can only talk to service B if policy, identity, and context all line up. That makes hidden east-west traffic visible and reduces accidental trust between agents, workloads, and managed identities. In NHI programs, it also helps expose overbroad service accounts, stale secrets, and legacy allow rules that quietly persist after deployments. Definitions vary across vendors when they stretch default deny to mean any blocked connection, but the stricter security meaning is policy-first, not merely outage-driven blocking. The most common misapplication is treating a perimeter firewall as default deny while internal services still accept broad wildcard access, which occurs when teams never translate application intent into workload-level policy.
Examples and Use Cases
Implementing default deny rigorously often introduces change-management overhead, requiring organisations to weigh rapid service onboarding against the cost of designing and maintaining explicit allow rules.
- A payment service only accepts traffic from a specific API gateway identity, not from the whole subnet, so lateral movement is constrained even if the network is compromised.
- A CI/CD runner can reach the artifact store but not production databases, because policy is bound to the runner’s NHI and environment context.
- An AI agent is allowed to call a secrets retrieval service only for one workflow step, with JIT access expiring after the task completes.
- A newly deployed microservice fails closed until its service account, mTLS identity, and RBAC rule are all reviewed and approved.
- An incident response team uses default deny to isolate suspicious workloads without shutting down the entire cluster.
These patterns align with the governance and lifecycle controls described in the Ultimate Guide to NHIs, especially where service account sprawl and excess privilege create hidden trust paths. They also map cleanly to NIST’s risk-based approach, which treats access control as an ongoing operational control rather than a one-time configuration. In mature environments, default deny is less about blocking everything and more about making every exception reviewable, attributable, and time-bound.
Why It Matters in NHI Security
Default deny matters because NHIs scale far faster than human identities, and every unchecked path becomes a durable attack surface. NHI Mgmt Group research shows that Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means permissive defaults can turn routine service-to-service connectivity into broad compromise opportunities. When teams rely on allow-by-default networking, service accounts often inherit access that was never intentionally granted, and attackers only need one weak path to pivot.
Default deny also supports Zero Trust Architecture by forcing identity verification, policy evaluation, and least privilege into every request path, which is consistent with NIST Cybersecurity Framework 2.0. It is especially important where secrets, tokens, and API keys are long-lived or embedded in automation, because a single leaked credential should not translate into implicit trust across the environment. Organisationally, the benefit is clearer blast-radius control and better auditability, but the cost is more policy design, testing, and exception handling. Organisations typically encounter the need for default deny only after an unexpected service-to-service breach, at which point the pattern becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust uses explicit policy enforcement instead of implicit network trust. |
| NIST CSF 2.0 | PR.AC | Access control under CSF supports least privilege and explicit authorization. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Default deny reduces NHI overprivilege and unintended trust paths. |
Block implicit access paths and require policy checks for every workload-to-workload request.
Related resources from NHI Mgmt Group
- Should security teams disable OneDrive auto-sync by default?
- What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
- What breaks when secrets are used as the default for workload access?
- What breaks when organisations keep passwords as the default identity control?
