A vulnerability scanner drops a report on the infrastructure desk. High severity: unencrypted internal communications. The scanner found port 80 open between the application servers and the database. The platform engineer notes that the cloud provider encrypts traffic between those specific instance types in hardware, below the guest operating system. The security architect asks for a packet capture to prove it. The platform engineer explains that a packet capture inside the virtual machine will only show plaintext, because the encryption happens at the physical network interface card before the packet leaves the server.

The scanner is accurate. The encryption is real. The disagreement is about which threat model they are trying to satisfy.

The hardware encryption boundary

Modern cloud infrastructure uses custom hardware cards inserted into the physical servers. The guest operating system sends plaintext HTTP. The hardware card intercepts the frames, encrypts them, and encapsulates them before sending them over the physical data center network. The receiving card decrypts them before handing them to the destination guest OS.

The application sees plain TCP. The physical data center network carries ciphertext. The provider manages the keys.

This mechanism protects against a compromised data center technician tapping a physical fiber line. It does not protect against an attacker who compromises an adjacent container and runs a packet sniffer. If the attacker has root access on the host, they capture the traffic before it hits the hypervisor’s encryption layer. Application-layer TLS just means they read the keys in memory instead of reading the packets on the virtual wire.

Deciding whether to add TLS

Leaving HTTP in place is the right decision when the connection’s actual path is covered by documented provider hardware encryption, the primary threat is physical interception of the network medium, and the data classification rules permit provider-operated protection. In this scenario, separate controls like network segmentation and workload identity adequately address lateral movement.

Application-layer TLS or mutual TLS is required when the conditions change. You must implement it if:

  • The accreditation body mandates customer-controlled keys for the specific data classification. This is common when separating distinct coalition intelligence feeds that share the same underlying infrastructure, where sharing the provider’s encryption fabric is unacceptable.
  • The traffic crosses an unverified segment where hardware encryption drops. The provider’s guarantee usually ends at the instance boundary. If traffic routes through a transit gateway, an internal load balancer, a legacy virtual machine, or a peering link to another environment, it may travel in plaintext.
  • The client needs to cryptographically authenticate the specific service it is talking to. Hardware encryption authenticates the network path, not the application workload.

The operational tax of application-layer encryption

It is tempting to implement mTLS everywhere to silence the automated compliance scanner. The operational cost of doing so is substantial.

Encrypting multi-gigabit streams of surveillance video or signal telemetry at the application layer doubles compute costs. Sidecar proxies in a service mesh add latency to every internal hop. For an application processing millions of intercepts per minute, that latency compounds, backing up ingest queues and crashing nodes.

Certificate rotation becomes a recurring operational burden. When an enterprise rotates internal TLS certificates, services break. A legacy database connector routing supply requests might not support modern cipher suites without a total rewrite, delaying a deployment by months.

Do not implement a service mesh just to satisfy a scanner. If you cannot articulate the specific threat that application-layer encryption mitigates beyond what the hardware already provides, you are paying an operational tax for compliance, not security.

Documenting the control inheritance

The auditor is looking for an encrypted payload. You are looking at an encrypted transport layer. You have to document the translation between the two.

You cannot prove hardware encryption with a packet capture from within the virtual machine. You must rely on architecture documentation and a formal control inheritance document.

To make the decision stick, write a formal decision record or system security plan entry that includes:

  • The specific flow, the data category, and the threat model.
  • References to the provider’s exact architecture whitepapers, mapping the deployment to the supported instance types to prove the inheritance is valid.
  • The compensating controls for lateral movement, such as security groups and workload attestation.
  • A change trigger. A topology change, such as adding a proxy, moving to a new instance family, or routing traffic across a gateway, invalidates the hardware encryption claim and requires a new review.

Keep the scanner finding accurate. If the risk is accepted via control inheritance, the application still uses HTTP. Document the scope and the inheritance rather than overriding the scanner or approving HTTP generally. Private addressing tells you where a packet is routed, not what protects it. The exception belongs to a defined flow, not to a subnet.

The scanner will still flag the port, but the threat model determines whether the data was ever actually exposed.