Check Azure Files per-protocol encryption settings instead of assuming creation defaults match

Source facts

For new storage accounts created in the Azure portal, the SMB and NFS encryption-in-transit requirements default to enabled. PowerShell, CLI and FileREST API creation leave these per-protocol choices Not selected for compatibility. On existing accounts, Secure transfer required continues governing SMB or NFS until its corresponding per-protocol setting is explicitly configured.

FileREST uses Secure transfer required: when enabled, FileREST access must use HTTPS. A Not selected protocol choice should therefore be investigated with the existing account setting, not simply reported as encryption disabled. Microsoft Learn.

Applicability

Identify the account’s creation path, actual settings and protocols used by its clients. Keep the review focused on effective requirements rather than a screenshot from a differently created account.

DSE recommendation

DSE recommends making intended encryption requirements explicit in the approved deployment design. Compare portal and automated provisioning results before standardizing a template. Investigate client compatibility through an approved test rather than disabling a requirement to reproduce an older default. Preserve the legacy setting when documenting why an unset protocol choice behaves as observed.

Verification

Inspect a representative deployment’s SMB, NFS and FileREST settings as applicable, then test the permitted encrypted path and an appropriate noncompliant test case. Record configuration and negotiated behavior separately. Confirm that a change to one protocol has the intended scope and does not leave another protocol’s requirement undocumented.

Official references

Microsoft Learn: Networking Considerations for Azure Files. Source retrieved September 9, 2026.