Side-Channel Attacks Guide: What Defenders Need to Know and Do

Side-channel attacks recover secrets such as cryptographic keys, passwords or another tenant's data by observing the physical or microarchitectural effects of a computation, rather than by breaking its logic. A side channel is any measurable by-product of processing, such as execution time, cache state, power draw or electromagnetic emissions, that varies with secret data. Since the 2018 disclosure of Spectre and Meltdown, CPU side channels have become a routine patching and configuration concern for anyone running shared infrastructure. This guide explains the main families at concept level and focuses on what defenders control: microcode and operating system mitigations, hypervisor and SMT settings, browser isolation, constant-time cryptography and physical protections. It is for infrastructure, cloud and platform engineers, cryptography owners and vulnerability managers, and it contains no exploitation detail.

Key takeaways

• The risk is about shared resources. Side channels matter most where untrusted code shares hardware with secrets: multi-tenant cloud hosts, virtualisation, browsers running third-party scripts and shared CI runners.
• Mitigation needs firmware and software together. Many CPU mitigations only become active when OEM firmware carrying updated microcode and an operating system update are both installed.
• Detection is weak, so prevention carries the load. The Meltdown and Spectre researchers note that exploitation likely leaves no traces in traditional log files.
• Secrets code needs constant-time design. Execution time must not vary with secret values, which means no secret-dependent branches or memory lookups in cryptographic code.
• Turning mitigations off is a risk decision. Linux mitigations=off or disabled Windows mitigations trade security for performance and should only apply to isolated, fully trusted workloads with documented approval.

What it is

Conventional attacks exploit a flaw in what a program does. Side-channel attacks exploit how it does it. If an operation on a secret takes slightly longer for some values, leaves different traces in a CPU cache, or draws different power, an observer who can measure that effect many times can infer the secret statistically. The software can be functionally correct and still leak.

CWE classifies the general weakness as CWE-203 Observable Discrepancy, with physical leakage under CWE-1300 Improper Protection of Physical Side Channels (power, electromagnetic and acoustic emissions). MITRE CAPEC catalogues related attack patterns including CAPEC-663 Exploitation of Transient Instruction Execution, CAPEC-462 Cross-Domain Search Timing and CAPEC-621 Analysis of Packet Timing and Sizes.

How it works

At concept level, every side-channel attack has three ingredients, and each is a lever for defenders.

1. A shared resource: the attacker and victim share something whose state depends on the victim's secret, such as a CPU core and its caches, a branch predictor, a network path or a power supply. Remove the sharing and the channel closes.
2. A secret-dependent behaviour: the victim's code takes a different path, touches different memory or runs for a different time depending on the secret. Constant-time code removes this dependence.
3. Measurement and inference: the attacker measures the effect repeatedly and uses statistics to recover the secret. Noise, coarse timers and limits on repeated attempts make this harder but rarely impossible.

Transient execution attacks add a CPU-level twist. Modern processors speculatively execute instructions before they know whether those instructions should run, then discard the results. The Meltdown and Spectre research showed that discarded work still leaves traces in microarchitectural state. Meltdown (CVE-2017-5754) broke the isolation between user applications and the operating system; Spectre (CVE-2017-5715 and CVE-2017-5753) broke isolation between applications. Researchers have since disclosed many related issues, which the Linux kernel documents individually, including MDS, L1TF, TSX Async Abort, MMIO Stale Data, Retbleed, SRSO, Gather Data Sampling, Register File Data Sampling, Indirect Target Selection and VMSCAPE.

Why it matters

• Isolation is a security boundary you depend on: cloud tenancy, virtual machines, containers on a shared kernel, browser tabs and the kernel itself all assume one workload cannot read another's memory. Transient execution flaws undermine that assumption. See the Hypervisor and Virtualisation Security Guide.
• Keys and credentials are the prize: the targets are usually small, high-value secrets: private keys, session keys, tokens and passwords. A leaked signing key or service credential gives an attacker a durable non-human identity, so key protection and rotation planning matter. See the Cryptographic Key Management Guide.
• Low visibility in exploitation data: none of the original Spectre and Meltdown CVEs appears in the CISA KEV catalogue (checked against version 2026.10.21). That reflects how hard in-the-wild use is to observe and prove, not proof of safety, and it means KEV-driven prioritisation alone will not schedule this work.
• Long tail of hardware: fixes depend on CPU generation, OEM firmware support and hypervisor updates, so older fleets can stay exposed for years. Hardware lifecycle decisions are part of the mitigation.

What defenders should do

Mitigation reference

Phased approach

1. Classify workloads by sharing: identify where untrusted code can run beside secrets: multi-tenant hosts, VDI, CI runners, shared Kubernetes nodes and browsers.
2. Baseline status: collect Linux sysfs vulnerability files and Windows SpeculationControl output across the fleet into your CMDB or vulnerability platform.
3. Patch in order: firmware and microcode, then hypervisor hosts, then guest and bare-metal operating systems. Test performance on a pilot ring first, since some mitigations have measurable cost.
4. Decide on SMT: for hosts running mutually untrusted workloads, disable SMT or adopt core scheduling; for single-tenant hosts, document the decision to keep SMT on.
5. Review exceptions: find any mitigations=off boot options or disabled Windows mitigations and require risk acceptance with an expiry date.
6. Fix application code paths: replace hand-written comparisons of secrets with constant-time library functions and move key operations into vetted libraries or HSMs.
7. Roll back safely: if a mitigation causes unacceptable regression, revert on the affected ring only, isolate those hosts from untrusted workloads, and track the exception.

Decision guidance

• Multi-tenant versus dedicated: shared hosts running other parties' code need full mitigations and SMT controls. Dedicated hosts running only your trusted code can accept a narrower set, but only with a documented assessment.
• Cloud consumer versus operator: cloud customers rely on the provider for host microcode and hypervisor patching, but still own guest OS mitigations and the choice of dedicated instances for the most sensitive keys. See the Confidential Computing Guide for hardware isolation options.
• Small versus large organisations: small teams should keep vendor defaults, patch promptly and avoid writing their own cryptography. Large operators need fleet-wide telemetry of mitigation status and a hardware refresh plan.

Detection and measurement

Because exploitation is hard to see in logs, measure exposure rather than attacks. Watch for unexpected untrusted code on sensitive hosts and for changes to boot parameters or mitigation registry settings through configuration monitoring.

• Share of hosts reporting "Vulnerable" in any Linux sysfs vulnerability file or a False enablement value in SpeculationControl output.
• Firmware currency: share of servers on the latest OEM firmware with current microcode.
• Exception count and age: hosts with mitigations=off or disabled mitigations, and days since approval.
• SMT posture on multi-tenant hosts: share with SMT disabled or core scheduling enforced.
• Secret comparisons fixed: open static analysis findings for non-constant-time comparisons of secrets.

Common misconceptions

• "A software patch is enough." Many mitigations show "hardware support present: False" until OEM firmware with new microcode is installed.
• "Side channels are academic." Browser vendors, operating systems and hypervisors restructured isolation because of them, and new variants continue to be disclosed.
• "Encryption protects us." Side channels target the key while it is in use, and traffic analysis can infer content from encrypted sessions.
• "Constant-time crypto makes the whole system safe." BearSSL's guidance warns that constant-time code does not by itself guarantee timing immunity for the whole system, and compilers can introduce variable-time code.
• "Cloud providers handle all of it." Providers patch hosts, but guest kernels, browsers and application code remain the customer's job.

Common failure patterns

• Guests patched, hosts not: VM images updated while hypervisor hosts run old microcode, so guest mitigations report as unsupported.
• Performance tuning becomes permanent: mitigations=off added for a benchmark and left in a golden image.
• Server defaults misunderstood: assuming Windows Server has the same default mitigations as client Windows.
• Home-grown secret comparison: API keys or HMACs compared with an ordinary early-exit string comparison.
• Shared runners for sensitive builds: signing keys used on CI runners that also execute untrusted pull request code.

Related concepts

Related topics: memory disclosure through software bugs rather than hardware effects is covered in the Memory Corruption Vulnerabilities Guide; boot and microcode delivery in the Firmware and Boot Security Guide; and cryptographic foundations in the Cryptography Basics Guide.

Practitioner checklist

• Inventory hosts where untrusted code shares hardware with secrets.
• Collect sysfs vulnerability status and SpeculationControl output fleet-wide and alert on "Vulnerable" or False.
• Patch firmware and microcode, then hypervisors, then guests, using a pilot ring.
• Disable SMT or enforce core scheduling on multi-tenant hosts, and record the decision for single-tenant hosts.
• Remove mitigations=off and disabled mitigations, or approve them with an expiry date.
• Replace secret comparisons with constant-time library functions and keep keys in vetted libraries or HSMs.
• Keep browsers current with site isolation enabled.
• Specify side-channel resistance when buying HSMs, smart cards and embedded devices.

Standards and references

• Linux kernel documentation: Hardware vulnerabilities
• Microsoft: Understanding Get-SpeculationControlSettings PowerShell script output
• Intel: Software Security Guidance
• Graz University of Technology researchers: Meltdown and Spectre
• MITRE: CWE-1300 Improper Protection of Physical Side Channels
• MITRE CAPEC: Exploitation of Transient Instruction Execution
• Chromium: Site Isolation
• BearSSL: Constant-Time Crypto

Related NHI Mgmt Group resources: Hypervisor and Virtualisation Security Guide · Confidential Computing Guide · Cryptographic Key Management Guide · Patch Management Guide · Memory Corruption Vulnerabilities Guide