Tell a room of IT people that your file shares are reachable over SMB port 445 from the open internet and watch the faces. That reflex was earned honestly, by WannaCry and two decades of SMB1 horror stories. But a risk model built on reflex is not a risk model, and the actual security posture of Azure Files’ public endpoint deserves to be argued on facts. So let us argue it, and then design the three access paths I actually deploy.
What is actually exposed
Every storage account has a public endpoint, and for file shares that means SMB over TCP 445 to a globally resolvable name. Microsoft’s own documentation is more candid about this than its critics expect: it states plainly that SMB 3.x is an internet-safe protocol and that the widespread blocking of port 445 originates from legacy guidance about deprecated versions of SMB. That claim rests on something concrete. Unencrypted SMB, whether the ancient 2.1 dialect or 3.x without encryption, is only possible from within the same Azure region as the share, and only when you have deliberately disabled the encryption requirement. From anywhere that matters, the conversation is SMB 3.1.1 with AES-GCM channel encryption, negotiated with pre-authentication integrity, which is cryptographic machinery comparable to the TLS session protecting your bank login. New accounts created in the portal require encryption in transit by default. Nobody is sniffing your spreadsheets off the wire.
So the packet capture argument is dead. What remains is the real risk model, and it has three parts. First, the endpoint is discoverable and accepts connection attempts from the entire internet, which means authentication is the whole perimeter. Second, one of the two supported credentials is the storage account key, a passwordless-in-the-worst-sense secret with full control, no MFA, no Conditional Access, and no name attached; a leaked key is a leaked share, from anywhere. Third, as the identity article established, even Kerberos-authenticated SMB cannot carry an MFA challenge, so the strongest per-user control on the flow is the initial device sign-in. The honest summary: the public endpoint’s cryptography is fine, its authentication surface is the thing you are defending, and your defense budget should be spent on killing key-based access and deciding where enforcement lives.
There is also a fourth fact, not about risk but about physics: much of the consumer internet will not carry your packets. Most large residential cable providers and nearly all phone hotspots block outbound 445, a policy frozen in place by history and unlikely to thaw. Fiber providers, business circuits, and corporate egress mostly allow it, but “mostly” is doing heavy lifting. A remote workforce on the public endpoint plays a reachability lottery every morning, and that, more than any security argument, is why the public endpoint is rarely my production answer for user traffic.
The public endpoint’s cryptography is not the problem. The problem is that authentication is the entire perimeter, and SMB authentication cannot ask for a second factor.
The three paths that carry production traffic
The first path is the private endpoint over infrastructure you already trust. The storage account grows a network interface inside your VNet with a private IP, the public endpoint gets locked down or disabled, and SMB rides your site-to-site VPN or ExpressRoute exactly as it rides your LAN today. This is the natural posture for organizations that already have hub networking: the office feels nothing, the firewall team keeps its perimeter, and the failure modes are all DNS, which is why the build sheet for this path spends half its steps on the privatelink DNS zone and the split-horizon trap. If you have a VPN and an estate that works in offices, this is your default.
The second path is the security service edge, and it is the one that answers the MFA problem. Global Secure Access, or any SASE product in the same architectural family, tunnels the client’s port 445 traffic through an identity-aware broker to the share’s private endpoint. The SMB flow itself still cannot do MFA, but the network segment carrying it now can: Conditional Access evaluates the user, the device, and the risk before the tunnel opens, which is exactly the compensating control the CA exclusion from the identity build sheet demands. This is the modern answer for remote-heavy, cloud-native estates with no VPN estate to preserve, and it deserves the caveat I will repeat in its build sheet: the generic pattern of publishing SMB through Global Secure Access is first-party documented, while the specific pairing with an Azure Files private endpoint is a pattern the practitioner community has proven rather than one Microsoft’s docs walk you through. It works, I deploy it, and you should test it in your own tenant before you bet the migration on it.
The third path is not carrying SMB across the WAN at all: Azure File Sync puts a Windows Server cache at the site, users mount the server over the LAN, and only sync traffic, HTTPS on 443, crosses the internet. That path solves latency and the 445 lottery in one move and gets its own pair of articles later in the series. And for completeness, the path Azure Files does not offer: SMB over QUIC, the 443-based SMB transport Windows Server 2025 made mainstream, is still not natively supported by the service. If QUIC is the answer your remote estate needs, today it arrives via a File Sync server running on Windows Server, not via the share itself. Watch that space; native QUIC would rewrite this article, and I will rewrite it the week that ships.
Choosing, in practice
My decision usually falls out of two questions: does the estate already own trusted transit, and where do users sit. An office-anchored organization with a VPN or ExpressRoute takes the private endpoint and is done; the build sheet is [AF 3.1]. A distributed, cloud-native organization takes Global Secure Access, gets Conditional Access on file traffic as the prize, and accepts the client-agent dependency; that is [AF 3.2]. Branch-heavy estates with latency-sensitive habits take File Sync caches. The hardened public endpoint remains legitimate in narrow lanes: pilots like the one this series built, small single-site shops whose ISP allows 445 and whose threat model accepts identity-only mounts, and machine-to-machine access from known egress IPs pinned in the storage firewall. What I do not accept is drift: pick a posture on purpose, write down why, and let the storage firewall enforce the decision, because a share that is accidentally on three paths at once is on none of them deliberately.
Azure Files
‹ Previous: [AF 2.1] Build Sheet: Cloud-Native Identity for Azure Files
Next: [AF 3.1] Build Sheet: Private Endpoint, DNS, and the Locked-Down Share ›
