What is the firewall policy: deny all by default, permit by exception?
Almost every organisation denies inbound by default. Very few deny outbound, and the outbound direction is where the question earns its place.
What the carrier is actually asking
The carrier is asking whether traffic is blocked unless explicitly permitted. The unstated part is direction: inbound deny-by-default is universal, outbound deny-by-default is rare and considerably more valuable against an active intrusion.
Why it is underwritten
Malware needs to reach its infrastructure. Data needs a route out. Outbound filtering interrupts both, and it converts a successful intrusion into a stalled one. Carriers that ask this question are usually probing for the outbound half.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Cloud egress posture is measurable, and it is where most estates find they are fully permissive.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Azure | Network security group outbound rules and the default allow-internet rule | Whether the default outbound allow has been overridden, which it usually has not |
| Azure | Azure Firewall or network virtual appliance egress rules | Explicit egress allow-list by destination and category rather than blanket permission |
| Azure | Default network access rule on storage accounts | Set to deny, so access is by exception rather than by default |
| Azure | Service endpoints and private endpoints for platform services | Traffic to platform services stays on the backbone rather than traversing the internet |
| On-premises | Outbound firewall policy and its rule base | Egress restricted by destination and port. Attested |
Cloud network security groups allow all outbound internet traffic by default. Unless someone deliberately overrode it, your workloads can reach any address on the internet, which is exactly what an implant relies on. Checking this takes minutes.
What a defensible yes requires
- Inbound is deny-by-default with justified exceptions.
- Outbound is restricted rather than fully permissive, at least for server workloads.
- Platform service traffic uses private paths rather than public endpoints.
- Rules have owners and justifications, so the exception list is reviewable.
- The posture is verified in the current configuration rather than assumed from design.
How this answer goes wrong
The answer describes inbound policy and outbound is unrestricted for the whole estate. Servers that never legitimately initiate internet connections can reach anything, which is the condition every remote access implant requires.
Frequently asked
Is outbound filtering practical?
For servers, very. Their destinations are few and known. For user devices it is harder and usually delivered through web filtering rather than firewall rules.
What breaks when we restrict egress?
Update services, telemetry, and licensing checks, all of which are discoverable in advance. Starting with a new server workload avoids retrofitting.
Do private endpoints help?
Considerably. They keep platform service traffic off the internet entirely, which shrinks what egress rules need to permit.
How does this relate to the allow-list question?
It is the same principle at a different scope. A separate question asks about allow-listing traffic to critical servers, and the answers should be consistent.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture