Is sensitive data encrypted in transit?
Nearly always yes for public traffic. The interesting parts are internal traffic, legacy protocol support, and the certificate nobody is watching.
What the carrier is actually asking
The carrier is asking whether sensitive data is protected while moving: to and from your public services, between your systems, and to third parties. Modern platforms default to encrypted transport, so the meaningful part of the answer concerns the exceptions.
Why it is underwritten
Interception matters less than it once did on public networks and matters considerably inside compromised environments, where attackers position themselves to capture credentials and data in motion. Encryption in transit also affects notification analysis, since data intercepted in clear text is more clearly disclosed than data captured in an encrypted stream.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is one of the most directly measurable questions on the application, and several of the settings are visible from outside as well as inside.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Azure | Minimum TLS version on storage accounts, key vaults, and databases | TLS 1.2 or higher enforced everywhere rather than left at a permissive default |
| Azure | HTTPS redirect and TLS version on web applications and gateways | HTTP redirected to HTTPS, and the current TLS version in use on public endpoints |
| Azure | Secure transfer required on storage accounts | Enabled, since without it a storage account accepts unencrypted requests |
| Microsoft 365 | Mail transport security and any opportunistic TLS configuration | Encrypted transport to partners, with enforced TLS for those handling regulated data |
| Certificates | Certificate expiry monitoring for public endpoints | Expiry alerting, since an expired certificate is the most common way transport security fails visibly |
Public endpoints are almost always encrypted because browsers demand it. Internal service-to-service calls, database connections, and management traffic frequently are not, and that is the traffic an attacker inside the network is positioned to read.
What a defensible yes requires
- A minimum TLS version is enforced across services rather than left at platform defaults.
- Unencrypted transport is refused rather than merely discouraged.
- Internal service and database connections are encrypted, not only public traffic.
- Mail to partners handling regulated data uses enforced rather than opportunistic encryption.
- Certificates are inventoried with expiry alerting.
How this answer goes wrong
The public website scores well and a legacy internal application still speaks unencrypted to its database, or a storage account accepts unencrypted requests because secure transfer was never required. Both are quiet, both are measurable, and neither shows up in an external scan.
Frequently asked
Is TLS 1.2 still acceptable?
Yes, as a minimum. Older versions should be disabled entirely, and 1.3 where supported. The important part is that a minimum is enforced rather than assumed.
Does this include email?
Mail uses opportunistic encryption by default, which can fall back to clear text. For partners handling regulated data, enforced TLS on a connector is the stronger position.
What about internal traffic on a private network?
It counts. Assuming the internal network is trusted is exactly the assumption that lateral movement exploits.
How is this verified?
Platform settings for the services you run, and an external scan for public endpoints. Both are quick and produce concrete evidence.
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