diff --git a/docs/threat_model/firmware_threat_model/index.rst b/docs/threat_model/firmware_threat_model/index.rst
index 05b6710..ce1752f 100644
--- a/docs/threat_model/firmware_threat_model/index.rst
+++ b/docs/threat_model/firmware_threat_model/index.rst
@@ -30,7 +30,7 @@
    threat_model
    threat_model_el3_spm
    threat_model_fvp_r
-   threat_model_rss_interface
+   threat_model_rse_interface
    threat_model_arm_cca
    threat_model_fw_update_and_recovery
 
diff --git a/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst b/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst
index 025d2d9..3b391c1 100644
--- a/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst
+++ b/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst
@@ -1,41 +1,41 @@
-Threat Model for RSS - AP interface
+Threat Model for RSE - AP interface
 ***********************************
 
 ************
 Introduction
 ************
 This document is an extension for the general TF-A threat-model. It considers
-those platforms where a Runtime Security Subsystem (RSS) is included in the SoC
+those platforms where a Runtime Security Engine (RSE) is included in the SoC
 next to the Application Processor (AP).
 
 ********************
 Target of Evaluation
 ********************
-The scope of this threat model only includes the interface between the RSS and
+The scope of this threat model only includes the interface between the RSE and
 AP. Otherwise, the TF-A :ref:`Generic Threat Model` document is applicable for
-the AP core. The threat model for the RSS firmware will be provided by the RSS
+the AP core. The threat model for the RSE firmware will be provided by the RSE
 firmware project in the future.
 
 
 Data Flow Diagram
 =================
 This diagram is different only from the general TF-A data flow diagram in that
-it includes the RSS and highlights the interface between the AP and the RSS
-cores. The interface description only focuses on the AP-RSS interface the rest
+it includes the RSE and highlights the interface between the AP and the RSE
+cores. The interface description only focuses on the AP-RSE interface the rest
 is the same as in the general TF-A threat-model document.
 
-.. uml:: ../../resources/diagrams/plantuml/tfa_rss_dfd.puml
-  :caption: Figure 1: TF-A Data Flow Diagram including RSS
+.. uml:: ../../resources/diagrams/plantuml/tfa_rse_dfd.puml
+  :caption: Figure 1: TF-A Data Flow Diagram including RSE
 
-.. table:: Table 1: TF-A - RSS data flow diagram
+.. table:: Table 1: TF-A - RSE data flow diagram
 
   +-----------------+--------------------------------------------------------+
   | Diagram Element | Description                                            |
   +=================+========================================================+
-  |       DF7       | | Boot images interact with RSS over a communication   |
+  |       DF7       | | Boot images interact with RSE over a communication   |
   |                 |   channel to record boot measurements and get image    |
   |                 |   verification keys. At runtime, BL31 obtains the      |
-  |                 |   realm world attestation signing key from RSS.        |
+  |                 |   realm world attestation signing key from RSE.        |
   +-----------------+--------------------------------------------------------+
 
 Threat Assessment
@@ -44,12 +44,12 @@
 threat-model document, :ref:`Generic Threat Model`. All the threats listed there
 are applicable for the AP core, here only the differences are highlighted.
 
-    - ID 11: The access to the communication interface between AP and RSS is
+    - ID 11: The access to the communication interface between AP and RSE is
       allowed only for firmware running at EL3. Accidentally exposing this
-      interface to NSCode can allow malicious code to interact with RSS and
+      interface to NSCode can allow malicious code to interact with RSE and
       gain access to sensitive data.
     - ID 13: Relevant in the context of the realm attestation key, which can be
-      retrieved by BL31 through DF7. The RSS communication protocol layer
+      retrieved by BL31 through DF7. The RSE communication protocol layer
       mitigates against this by clearing its internal buffer when reply is
       received. The caller of the API must do the same if data is not needed
       anymore.
diff --git a/docs/threat_model/supply_chain_threat_model.rst b/docs/threat_model/supply_chain_threat_model.rst
index 386a4b0..a0fed5c 100644
--- a/docs/threat_model/supply_chain_threat_model.rst
+++ b/docs/threat_model/supply_chain_threat_model.rst
@@ -115,7 +115,7 @@
 - *EDK2 UEFI*: Normal world bootloader from the EDK2 project [7]_. We use EDK2
   UEFI binaries hosted on tf.org servers for testing [8]_.
 
-Other software components used to test TF-A include U-Boot, Linux kernel, RSS,
+Other software components used to test TF-A include U-Boot, Linux kernel, RSE,
 MCP, and file systems, all sourced from the Arm Reference Platforms teams.
 
 TF-A Toolchain