What do security teams get wrong about encrypted command and control traffic?

Why This Matters for Security Teams

encrypted command and control traffic is dangerous because encryption can make malicious traffic look “normal” to tools that focus only on payload inspection. The real failure is not that traffic is encrypted. It is that a system, process, or non-human identity is communicating in a way that does not match its expected role, location, or timing.

That is why packet content alone is a weak signal. A service account that suddenly reaches out over HTTPS, WebSockets, or DNS-over-HTTPS may still be doing something operationally abnormal even if every byte is encrypted. NIST Cybersecurity Framework 2.0 pushes teams toward asset context, risk-based monitoring, and recovery outcomes rather than blind reliance on protocol visibility.

NHIMG research shows how often this gap becomes operational. In the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams discover encrypted command and control only after an internal workload has already begun beaconing, rather than through intentional identity-aware detection.

How It Works in Practice

Effective detection starts by establishing what “normal” looks like for each asset and each identity. That means correlating network flow, endpoint telemetry, authentication events, DNS patterns, certificate details, and workload identity rather than treating all HTTPS as equivalent. Current guidance suggests prioritising context-rich detections over protocol-only rules, especially where agents, scripts, CI/CD jobs, and service accounts have network reach beyond their business purpose.

Security teams typically reduce blind spots by combining:

• Identity-aware baselines for service accounts, API keys, and workloads
• Allowlists for expected destinations, ports, and certificate chains
• Detection of rare parent-child process chains and unusual egress timing
• Policy checks for encrypted DNS, tunnelling, and proxy abuse
• Central logging for token use, secret access, and outbound session creation

This is where the NIST model and NHIMG guidance align closely. NIST Cybersecurity Framework 2.0 supports continuous monitoring and asset awareness, while the NHIMG standards guidance for NHIs emphasizes lifecycle visibility, rotation, and least privilege. The practical implication is simple: if a workload should never initiate broad outbound connections, encrypted traffic is still suspicious even when it passes TLS validation.

Teams also need to separate secure transport from trusted behaviour. A valid certificate does not prove a process is legitimate, and encryption does not prevent lateral movement, credential replay, or covert exfiltration. These controls tend to break down in heavily proxied enterprise networks and east-west traffic inside flat environments because baseline behaviour becomes noisy and identity ownership is unclear.

Common Variations and Edge Cases

Tighter inspection often increases operational overhead, requiring organisations to balance detection depth against privacy, performance, and false positives. That tradeoff is especially visible in cloud-native environments, remote worker networks, and service meshes where many legitimate services already use encrypted transport by default.

There is no universal standard for this yet, but current guidance suggests treating these cases differently:

• DNS-over-HTTPS may be legitimate for privacy, but unusual destinations or rare client behavior still matter.
• Mutual TLS can authenticate endpoints, yet it does not prove the session is expected for that workload.
• Managed agents and automation may generate bursty encrypted traffic, so timing and destination baselines are essential.
• Cloud workloads may rotate identities frequently, making asset-owner mapping and runtime context more important than static IP reputation.

In high-volume environments, encrypted command and control often hides in plain sight when defenders over-trust “approved” protocols or overfit detections to known malware families. The better question is whether the asset, identity, and behaviour fit the mission. For a broader governance view, The State of Non-Human Identity Security shows why visibility and monitoring gaps remain common, and why NIST Cybersecurity Framework 2.0 remains useful as a control anchor. Detection breaks down most often when encrypted traffic is concentrated in shared egress gateways because attribution to the originating workload is lost.

Related resources from NHI Mgmt Group

• What do security teams get wrong about patching zero-days in control-plane software?
• What do security teams get wrong about same-origin upload handling?
• What do security teams get wrong about moving requests across teams?
• What do security teams get wrong about local developer services?