diff --git a/getting_started/intel_debug/introduction.rst b/getting_started/intel_debug/introduction.rst
index 8129bfef..e685b4af 100644
--- a/getting_started/intel_debug/introduction.rst
+++ b/getting_started/intel_debug/introduction.rst
@@ -104,6 +104,19 @@ installing their own firmware. Notable exceptions include Google
 Chromebooks and Up2/Up-Extreme boards, where the 'community key' is
 used.
 
+The Intel ME (Management Engine) is responsible for authentication of
+the firmware, be it signed by an Intel production key (consumer
+products), a community key (open development systems and Chromebooks
+since GeminiLake) or an OEM key. If the Intel ME is disabled by an
+OEM, or disabled by user-accessible BIOS options, the firmware
+authentication will fail and the firmware boot will not complete. If
+the ME was disabled by the OEM, the only solution will be to fall-back
+to the legacy HDAudio driver. If the ME was disabled by the user, they
+will have to re-enable it. There is unfortunately no documented
+mechanism for the Linux kernel to query if the firmware authentication
+is enabled or not, which means dmesg logs cannot be provided to alert
+the user to a ME configuration issue.
+
 2. Topology file
 ----------------
 
@@ -126,4 +139,4 @@ drivers and should work when changing the ``dsp_driver`` parameter.
 The selection of firmware, topology, and UCM files is based on platform
 capabilities, codec names, and DMI options. While the SOF team and the
 community try to cover all possible cases, errors will happen when the
-wrong file is selected at any of the three layers.
\ No newline at end of file
+wrong file is selected at any of the three layers.
diff --git a/getting_started/intel_debug/suggestions.rst b/getting_started/intel_debug/suggestions.rst
index 52058861..afbd62cb 100644
--- a/getting_started/intel_debug/suggestions.rst
+++ b/getting_started/intel_debug/suggestions.rst
@@ -27,6 +27,31 @@ enable two of the four speakers present. All of these cases are orthogonal
 to SOF issues in that the SOF driver cannot compensate for codec driver
 problems on its own.
 
+Try booting into Windows first, then reboot into Linux
+******************************************************
+
+On some platforms, e.g. with an HDaudio codec connected to amplifiers
+over an I2C/I2S link, the codec driver needs to perform a set of
+amplifier configurations. This is often handled in Windows but not in
+Linux codec drivers. A classic example of such issues is when
+headphone playback works, but speaker playback does not (or not on all
+speakers).
+
+This sort of issues will also happen with the HDaudio legacy driver
+and are not SOF bugs proper. To fix such issues, it is necessary to
+either get direct support from the codec vendor, or alternatively to
+reverse-engineer the missing configuration by snooping HDaudio
+commands in a Windows environment.
+
+Make sure the ME is enabled
+***************************
+
+If the ME is disabled by the OEM or the user, firmware authentication
+will fail without any explicit feedback provided to the user. In case
+of any authentication failure, the user should verify that the ME is
+not disabled, more information about the ME in the "firmware binary"
+section above.
+
 Test at the ALSA 'hw' device level
 **********************************