diff --git a/docs/threat_model/firmware_threat_model/index.rst b/docs/threat_model/firmware_threat_model/index.rst
new file mode 100644
index 0000000..05b6710
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/index.rst
@@ -0,0 +1,41 @@
+TF-A Firmware Threat Model
+==========================
+
+As the TF-A codebase is highly configurable to allow tailoring it best for each
+platform's needs, providing a holistic threat model covering all of its features
+is not necessarily the best approach. Instead, we provide a collection of
+documents which, together, form the project's threat model. These are
+articulated around a core document, called the :ref:`Generic Threat Model`,
+which focuses on the most common configuration we expect to see. The other
+documents typically focus on specific features not covered in the core document.
+
+As the TF-A codebase evolves and new features get added, these threat model
+documents will be updated and extended in parallel to reflect at best the
+current status of the code from a security standpoint.
+
+   .. note::
+
+      Although our aim is eventually to provide threat model material for all
+      features within the project, we have not reached that point yet. We expect
+      to gradually fill these gaps over time.
+
+Each of these documents give a description of the target of evaluation using a
+data flow diagram, as well as a list of threats we have identified using the
+`STRIDE threat modeling technique`_ and corresponding mitigations.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents
+
+   threat_model
+   threat_model_el3_spm
+   threat_model_fvp_r
+   threat_model_rss_interface
+   threat_model_arm_cca
+   threat_model_fw_update_and_recovery
+
+--------------
+
+*Copyright (c) 2021-2024, Arm Limited and Contributors. All rights reserved.*
+
+.. _STRIDE threat modeling technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
diff --git a/docs/threat_model/firmware_threat_model/threat_model.rst b/docs/threat_model/firmware_threat_model/threat_model.rst
new file mode 100644
index 0000000..d93547f
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model.rst
@@ -0,0 +1,1106 @@
+Generic Threat Model
+********************
+
+************
+Introduction
+************
+
+This document provides a generic threat model for TF-A firmware.
+
+.. _Target of Evaluation:
+
+********************
+Target of Evaluation
+********************
+
+In this threat model, the target of evaluation is the Trusted
+Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1),
+the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as
+shown on Figure 1. Everything else on Figure 1 is outside of the scope of
+the evaluation.
+
+TF-A can be configured in various ways. In this threat model we consider
+only the most basic configuration. To that end we make the following
+assumptions:
+
+- All TF-A images are run from either ROM or on-chip trusted SRAM. This means
+  TF-A is not vulnerable to an attacker that can probe or tamper with off-chip
+  memory.
+
+- Trusted boot is enabled. This means an attacker can't boot arbitrary images
+  that are not approved by platform providers.
+
+- There is no Secure-EL2. We don't consider threats that may come with
+  Secure-EL2 software.
+
+- There are no Root and Realm worlds. These are introduced by :ref:`Realm
+  Management Extension (RME)`.
+
+  The :ref:`Threat Model for TF-A with Arm CCA support` covers these types of
+  configurations.
+
+- No experimental features are enabled. We do not consider threats that may come
+  from them.
+
+- The platform's hardware complies with the `PSR specification`_, defining the
+  bare-minimum security prerequisites for System-on-Chips (SoC).
+
+Data Flow Diagram
+=================
+
+Figure 1 shows a high-level data flow diagram for TF-A. The diagram
+shows a model of the different components of a TF-A-based system and
+their interactions with TF-A. A description of each diagram element
+is given on Table 1. On the diagram, the red broken lines indicate
+trust boundaries. Components outside of the broken lines
+are considered untrusted by TF-A.
+
+.. uml:: ../../resources/diagrams/plantuml/tfa_dfd.puml
+  :caption: Figure 1: TF-A Data Flow Diagram
+
+.. table:: Table 1: TF-A Data Flow Diagram Description
+
+  +-----------------+--------------------------------------------------------+
+  | Diagram Element | Description                                            |
+  +=================+========================================================+
+  |       DF1       | | At boot time, images are loaded from non-volatile    |
+  |                 |   memory and verified by TF-A boot firmware. These     |
+  |                 |   images include TF-A BL2 and BL31 images, as well as  |
+  |                 |   other secure and non-secure images.                  |
+  +-----------------+--------------------------------------------------------+
+  |       DF2       | | TF-A log system framework outputs debug or           |
+  |                 |   informative messages over a UART interface.          |
+  |                 |                                                        |
+  |                 | | Also, characters can be read from a UART interface.  |
+  +-----------------+--------------------------------------------------------+
+  |       DF3       | | Debug and trace IP on a platform can allow access    |
+  |                 |   to registers and memory of TF-A.                     |
+  +-----------------+--------------------------------------------------------+
+  |       DF4       | | Secure world software (e.g. trusted OS) interact     |
+  |                 |   with TF-A through SMC call interface and/or shared   |
+  |                 |   memory.                                              |
+  +-----------------+--------------------------------------------------------+
+  |       DF5       | | Non-secure world software (e.g. rich OS) interact    |
+  |                 |   with TF-A through SMC call interface and/or shared   |
+  |                 |   memory.                                              |
+  +-----------------+--------------------------------------------------------+
+  |       DF6       | | This path represents the interaction between TF-A and|
+  |                 |   various hardware IPs such as TrustZone controller    |
+  |                 |   and GIC. At boot time TF-A configures/initializes the|
+  |                 |   IPs and interacts with them at runtime through       |
+  |                 |   interrupts and registers.                            |
+  +-----------------+--------------------------------------------------------+
+
+
+.. _threat_analysis:
+
+***************
+Threat Analysis
+***************
+
+In this section we identify and provide assessment of potential threats to TF-A
+firmware. The threats are identified for each diagram element on the
+data flow diagram above.
+
+For each threat, we identify the *asset* that is under threat, the
+*threat agent* and the *threat type*. Each threat is given a *risk rating*
+that represents the impact and likelihood of that threat. We also discuss
+potential mitigations.
+
+Assets
+======
+
+We have identified the following assets for TF-A:
+
+.. table:: Table 2: TF-A Assets
+
+  +--------------------+---------------------------------------------------+
+  | Asset              | Description                                       |
+  +====================+===================================================+
+  | Sensitive Data     | | These include sensitive data that an attacker   |
+  |                    |   must not be able to tamper with (e.g. the Root  |
+  |                    |   of Trust Public Key) or see (e.g. secure logs,  |
+  |                    |   debugging information such as crash reports).   |
+  +--------------------+---------------------------------------------------+
+  | Code Execution     | | This represents the requirement that the        |
+  |                    |   platform should run only TF-A code approved by  |
+  |                    |   the platform provider.                          |
+  +--------------------+---------------------------------------------------+
+  | Availability       | | This represents the requirement that TF-A       |
+  |                    |   services should always be available for use.    |
+  +--------------------+---------------------------------------------------+
+
+Threat Agents
+=============
+
+To understand the attack surface, it is important to identify potential
+attackers, i.e. attack entry points. The following threat agents are
+in scope of this threat model.
+
+.. table:: Table 3: Threat Agents
+
+  +-------------------+-------------------------------------------------------+
+  | Threat Agent      | Description                                           |
+  +===================+=======================================================+
+  |   NSCode          | | Malicious or faulty code running in the Non-secure  |
+  |                   |   world, including NS-EL0 NS-EL1 and NS-EL2 levels    |
+  +-------------------+-------------------------------------------------------+
+  |   SecCode         | | Malicious or faulty code running in the secure      |
+  |                   |   world, including S-EL0 and S-EL1 levels             |
+  +-------------------+-------------------------------------------------------+
+  |   AppDebug        | | Physical attacker using  debug signals to access    |
+  |                   |   TF-A resources                                      |
+  +-------------------+-------------------------------------------------------+
+  |  PhysicalAccess   | | Physical attacker having access to external device  |
+  |                   |   communication bus and to external flash             |
+  |                   |   communication bus using common hardware             |
+  +-------------------+-------------------------------------------------------+
+
+.. note::
+
+  In this threat model an advanced physical attacker that has the capability
+  to tamper with a hardware (e.g. "rewiring" a chip using a focused
+  ion beam (FIB) workstation or decapsulate the chip using chemicals) is
+  considered out-of-scope.
+
+Threat Types
+============
+
+In this threat model we categorize threats using the `STRIDE threat
+analysis technique`_. In this technique a threat is categorized as one
+or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``,
+``Information disclosure``, ``Denial of service`` or
+``Elevation of privilege``.
+
+Threat Risk Ratings
+===================
+
+For each threat identified, a risk rating that ranges
+from *informational* to *critical* is given based on the likelihood of the
+threat occurring if a mitigation is not in place, and the impact of the
+threat (i.e. how severe the consequences could be). Table 4 explains each
+rating in terms of score, impact and likelihood.
+
+.. table:: Table 4: Rating and score as applied to impact and likelihood
+
+  +-----------------------+-------------------------+---------------------------+
+  | **Rating (Score)**    | **Impact**              | **Likelihood**            |
+  +=======================+=========================+===========================+
+  | Critical (5)          | | Extreme impact to     | | Threat is almost        |
+  |                       |   entire organization   |   certain to be exploited.|
+  |                       |   if exploited.         |                           |
+  |                       |                         | | Knowledge of the threat |
+  |                       |                         |   and how to exploit it   |
+  |                       |                         |   are in the public       |
+  |                       |                         |   domain.                 |
+  +-----------------------+-------------------------+---------------------------+
+  | High (4)              | | Major impact to entire| | Threat is relatively    |
+  |                       |   organization or single|   easy to detect and      |
+  |                       |   line of business if   |   exploit by an attacker  |
+  |                       |   exploited             |   with little skill.      |
+  +-----------------------+-------------------------+---------------------------+
+  | Medium (3)            | | Noticeable impact to  | | A knowledgeable insider |
+  |                       |   line of business if   |   or expert attacker could|
+  |                       |   exploited.            |   exploit the threat      |
+  |                       |                         |   without much difficulty.|
+  +-----------------------+-------------------------+---------------------------+
+  | Low (2)               | | Minor damage if       | | Exploiting the threat   |
+  |                       |   exploited or could    |   would require           |
+  |                       |   be used in conjunction|   considerable expertise  |
+  |                       |   with other            |   and resources           |
+  |                       |   vulnerabilities to    |                           |
+  |                       |   perform a more serious|                           |
+  |                       |   attack                |                           |
+  +-----------------------+-------------------------+---------------------------+
+  | Informational (1)     | | Poor programming      | | Threat is not likely    |
+  |                       |   practice or poor      |   to be exploited on its  |
+  |                       |   design decision that  |   own, but may be used to |
+  |                       |   may not represent an  |   gain information for    |
+  |                       |   immediate risk on its |   launching another       |
+  |                       |   own, but may have     |   attack                  |
+  |                       |   security implications |                           |
+  |                       |   if multiplied and/or  |                           |
+  |                       |   combined with other   |                           |
+  |                       |   threats.              |                           |
+  +-----------------------+-------------------------+---------------------------+
+
+Aggregate risk scores are assigned to identified threats;
+specifically, the impact score multiplied by the likelihood score.
+For example, a threat with high likelihood and low impact would have an
+aggregate risk score of eight (8); that is, four (4) for high likelihood
+multiplied by two (2) for low impact. The aggregate risk score determines
+the finding's overall risk level, as shown in the following table.
+
+.. table:: Table 5: Overall risk levels and corresponding aggregate scores
+
+  +---------------------+-----------------------------------+
+  | Overall Risk Level  | Aggregate Risk Score              |
+  |                     | (Impact multiplied by Likelihood) |
+  +=====================+===================================+
+  | Critical            | 20–25                             |
+  +---------------------+-----------------------------------+
+  | High                | 12–19                             |
+  +---------------------+-----------------------------------+
+  | Medium              | 6–11                              |
+  +---------------------+-----------------------------------+
+  | Low                 | 2–5                               |
+  +---------------------+-----------------------------------+
+  | Informational       | 1                                 |
+  +---------------------+-----------------------------------+
+
+The likelihood and impact of a threat depends on the
+target environment in which TF-A is running. For example, attacks
+that require physical access are unlikely in server environments while
+they are more common in Internet of Things(IoT) environments.
+In this threat model we consider three target environments:
+``Internet of Things(IoT)``, ``Mobile`` and ``Server``.
+
+Threat Assessment
+=================
+
+The following threats were identified by applying STRIDE analysis on
+each diagram element of the data flow diagram.
+
+For each threat, we strive to indicate whether the mitigations are currently
+implemented or not. However, the answer to this question is not always straight
+forward. Some mitigations are partially implemented in the generic code but also
+rely on the platform code to implement some bits of it. This threat model aims
+to be platform-independent and it is important to keep in mind that such threats
+only get mitigated if the platform code properly fulfills its responsibilities.
+
+Also, some mitigations require enabling specific features, which must be
+explicitly turned on via a build flag.
+
+When such conditions must be met, these are highlighted in the ``Mitigations
+implemented?`` box.
+
+As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
+some threats are confined in specific images, while others apply to each of
+them. To help developers implement mitigations in the right place, threats below
+are categorized based on the firmware image that should mitigate them.
+
+.. _General Threats:
+
+General Threats for All Firmware Images
+---------------------------------------
+
++------------------------+---------------------------------------------------+
+| ID                     | 05                                                |
++========================+===================================================+
+| Threat                 | | **Information leak via UART logs**              |
+|                        |                                                   |
+|                        | | During the development stages of software it is |
+|                        |   common to print all sorts of information on the |
+|                        |   console, including sensitive or confidential    |
+|                        |   information such as crash reports with detailed |
+|                        |   information of the CPU state, current registers |
+|                        |   values, privilege level or stack dumps.         |
+|                        |                                                   |
+|                        | | This information is useful when debugging       |
+|                        |   problems before releasing the production        |
+|                        |   version but it could be used by an attacker     |
+|                        |   to develop a working exploit if left enabled in |
+|                        |   the production version.                         |
+|                        |                                                   |
+|                        | | This happens when directly logging sensitive    |
+|                        |   information and more subtly when logging        |
+|                        |   side-channel information that can be used by an |
+|                        |   attacker to learn about sensitive information.  |
++------------------------+---------------------------------------------------+
+| Diagram Elements       | DF2                                               |
++------------------------+---------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                    |
+| Components             |                                                   |
++------------------------+---------------------------------------------------+
+| Assets                 | Sensitive Data                                    |
++------------------------+---------------------------------------------------+
+| Threat Agent           | AppDebug                                          |
++------------------------+---------------------------------------------------+
+| Threat Type            | Information Disclosure                            |
++------------------------+------------------+----------------+---------------+
+| Application            | Server           | IoT            | Mobile        |
++------------------------+------------------+----------------+---------------+
+| Impact                 | N/A              | Low (2)        | Low (2)       |
++------------------------+------------------+----------------+---------------+
+| Likelihood             | N/A              | High (4)       | High (4)      |
++------------------------+------------------+----------------+---------------+
+| Total Risk Rating      | N/A              | Medium (8)     | Medium (8)    |
++------------------------+------------------+----------------+---------------+
+| Mitigations            | | Remove sensitive information logging in         |
+|                        |   production releases.                            |
+|                        |                                                   |
+|                        | | Do not conditionally log information depending  |
+|                        |   on potentially sensitive data.                  |
+|                        |                                                   |
+|                        | | Do not log high precision timing information.   |
++------------------------+---------------------------------------------------+
+| Mitigations            | | Yes / Platform Specific.                        |
+| implemented?           |   Requires the right build options to be used.    |
+|                        |                                                   |
+|                        | | Crash reporting is only enabled for debug       |
+|                        |   builds by default, see ``CRASH_REPORTING``      |
+|                        |   build option.                                   |
+|                        |                                                   |
+|                        | | The log level can be tuned at build time, from  |
+|                        |   very verbose to no output at all. See           |
+|                        |   ``LOG_LEVEL`` build option. By default, release |
+|                        |   builds are a lot less verbose than debug ones   |
+|                        |   but still produce some output.                  |
+|                        |                                                   |
+|                        | | Messages produced by the platform code should   |
+|                        |   use the appropriate level of verbosity so as    |
+|                        |   not to leak sensitive information in production |
+|                        |   builds.                                         |
++------------------------+---------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 06                                                 |
++========================+====================================================+
+| Threat                 | | **An attacker can read sensitive data and        |
+|                        |   execute arbitrary code through the external      |
+|                        |   debug and trace interface**                      |
+|                        |                                                    |
+|                        | | Arm processors include hardware-assisted debug   |
+|                        |   and trace features that can be controlled without|
+|                        |   the need for software operating on the platform. |
+|                        |   If left enabled without authentication, this     |
+|                        |   feature can be used by an attacker to inspect and|
+|                        |   modify TF-A registers and memory allowing the    |
+|                        |   attacker to read sensitive data and execute      |
+|                        |   arbitrary code.                                  |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF3                                                |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                     |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Code Execution, Sensitive Data                     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | AppDebug                                           |
++------------------------+----------------------------------------------------+
+| Threat Type            | Tampering, Information Disclosure,                 |
+|                        | Elevation of privilege                             |
++------------------------+------------------+---------------+-----------------+
+| Application            | Server           | IoT           | Mobile          |
++------------------------+------------------+---------------+-----------------+
+| Impact                 | N/A              | High (4)      | High (4)        |
++------------------------+------------------+---------------+-----------------+
+| Likelihood             | N/A              | Critical (5)  | Critical (5)    |
++------------------------+------------------+---------------+-----------------+
+| Total Risk Rating      | N/A              | Critical (20) | Critical (20)   |
++------------------------+------------------+---------------+-----------------+
+| Mitigations            | Disable the debug and trace capability for         |
+|                        | production releases or enable proper debug         |
+|                        | authentication as recommended by [`DEN0034`_].     |
++------------------------+----------------------------------------------------+
+| Mitigations            | | Platform specific.                               |
+| implemented?           |                                                    |
+|                        | | Configuration of debug and trace capabilities is |
+|                        |   entirely platform specific.                      |
++------------------------+----------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID                     | 08                                                   |
++========================+======================================================+
+| Threat                 | | **Memory corruption due to memory overflows and    |
+|                        |   lack of boundary checking when accessing resources |
+|                        |   could allow an attacker to execute arbitrary code, |
+|                        |   modify some state variable to change the normal    |
+|                        |   flow of the program, or leak sensitive             |
+|                        |   information**                                      |
+|                        |                                                      |
+|                        | | Like in other software, TF-A has multiple points   |
+|                        |   where memory corruption security errors can arise. |
+|                        |                                                      |
+|                        | | Some of the errors include integer overflow,       |
+|                        |   buffer overflow, incorrect array boundary checks,  |
+|                        |   and incorrect error management.                    |
+|                        |   Improper use of asserts instead of proper input    |
+|                        |   validations might also result in these kinds of    |
+|                        |   errors in release builds.                          |
++------------------------+------------------------------------------------------+
+| Diagram Elements       | DF4, DF5                                             |
++------------------------+------------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                       |
+| Components             |                                                      |
++------------------------+------------------------------------------------------+
+| Assets                 | Code Execution, Sensitive Data                       |
++------------------------+------------------------------------------------------+
+| Threat Agent           | NSCode, SecCode                                      |
++------------------------+------------------------------------------------------+
+| Threat Type            | Tampering, Information Disclosure,                   |
+|                        | Elevation of Privilege                               |
++------------------------+-------------------+-----------------+----------------+
+| Application            | Server            | IoT             | Mobile         |
++------------------------+-------------------+-----------------+----------------+
+| Impact                 | Critical (5)      | Critical (5)    | Critical (5)   |
++------------------------+-------------------+-----------------+----------------+
+| Likelihood             | Medium (3         | Medium (3)      | Medium (3)     |
++------------------------+-------------------+-----------------+----------------+
+| Total Risk Rating      | High (15)         | High (15)       | High (15)      |
++------------------------+-------------------+-----------------+----------------+
+| Mitigations            | | 1) Use proper input validation.                    |
+|                        |                                                      |
+|                        | | 2) Code reviews, testing.                          |
++------------------------+------------------------------------------------------+
+| Mitigations            | | 1) Yes.                                            |
+| implemented?           |   Data received from normal world, such as addresses |
+|                        |   and sizes identifying memory regions, are          |
+|                        |   sanitized before being used. These security checks |
+|                        |   make sure that the normal world software does not  |
+|                        |   access memory beyond its limit.                    |
+|                        |                                                      |
+|                        | | By default *asserts* are only used to check for    |
+|                        |   programming errors in debug builds. Other types of |
+|                        |   errors are handled through condition checks that   |
+|                        |   remain enabled in release builds. See              |
+|                        |   `TF-A error handling policy`_. TF-A provides an    |
+|                        |   option to use *asserts* in release builds, however |
+|                        |   we recommend using proper runtime checks instead   |
+|                        |   of relying on asserts in release builds.           |
+|                        |                                                      |
+|                        | | 2) Yes.                                            |
+|                        |   TF-A uses a combination of manual code reviews     |
+|                        |   and automated program analysis and testing to      |
+|                        |   detect and fix memory corruption bugs. All TF-A    |
+|                        |   code including platform code go through manual     |
+|                        |   code reviews. Additionally, static code analysis   |
+|                        |   is performed using Coverity Scan on all TF-A code. |
+|                        |   The code is also tested  with                      |
+|                        |   `Trusted Firmware-A Tests`_ on Juno and FVP        |
+|                        |   platforms.                                         |
++------------------------+------------------------------------------------------+
+
+
++------------------------+----------------------------------------------------+
+| ID                     | 11                                                 |
++========================+====================================================+
+| Threat                 | | **Misconfiguration of the Memory Management Unit |
+|                        |   (MMU) may allow a normal world software to       |
+|                        |   access sensitive data, execute arbitrary         |
+|                        |   code or access otherwise restricted HW           |
+|                        |   interface**                                      |
+|                        |                                                    |
+|                        | | A misconfiguration of the MMU could              |
+|                        |   lead to an open door for software running in the |
+|                        |   normal world to access sensitive data or even    |
+|                        |   execute code if the proper security mechanisms   |
+|                        |   are not in place.                                |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF5, DF6                                           |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                     |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Sensitive Data, Code execution                     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NSCode                                             |
++------------------------+----------------------------------------------------+
+| Threat Type            | Information Disclosure, Elevation of Privilege     |
++------------------------+-----------------+-----------------+----------------+
+| Application            | Server          | IoT             | Mobile         |
++------------------------+-----------------+-----------------+----------------+
+| Impact                 | Critical (5)    | Critical (5)    | Critical (5)   |
++------------------------+-----------------+-----------------+----------------+
+| Likelihood             | High (4)        | High (4)        | High (4)       |
++------------------------+-----------------+-----------------+----------------+
+| Total Risk Rating      | Critical (20)   | Critical (20)   | Critical (20)  |
++------------------------+-----------------+-----------------+----------------+
+| Mitigations            | When configuring access permissions, the           |
+|                        | principle of least privilege ought to be           |
+|                        | enforced. This means we should not grant more      |
+|                        | privileges than strictly needed, e.g. code         |
+|                        | should be read-only executable, read-only data     |
+|                        | should be read-only execute-never, and so on.      |
++------------------------+----------------------------------------------------+
+| Mitigations            | | Platform specific.                               |
+| implemented?           |                                                    |
+|                        | | MMU configuration is platform specific,          |
+|                        |   therefore platforms need to make sure that the   |
+|                        |   correct attributes are assigned to memory        |
+|                        |   regions.                                         |
+|                        |                                                    |
+|                        | | TF-A provides a library which abstracts the      |
+|                        |   low-level details of MMU configuration. It       |
+|                        |   provides well-defined and tested APIs.           |
+|                        |   Platforms are encouraged to use it to limit the  |
+|                        |   risk of misconfiguration.                        |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID                     | 13                                                  |
++========================+=====================================================+
+| Threat                 | | **Leaving sensitive information in the memory,    |
+|                        |   can allow an attacker to retrieve them.**         |
+|                        |                                                     |
+|                        | | Accidentally leaving not-needed sensitive data in |
+|                        |   internal buffers can leak them if an attacker     |
+|                        |   gains access to memory due to a vulnerability.    |
++------------------------+-----------------------------------------------------+
+| Diagram Elements       | DF4, DF5                                            |
++------------------------+-----------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                      |
+| Components             |                                                     |
++------------------------+-----------------------------------------------------+
+| Assets                 | Sensitive Data                                      |
++------------------------+-----------------------------------------------------+
+| Threat Agent           | NSCode, SecCode                                     |
++------------------------+-----------------------------------------------------+
+| Threat Type            | Information Disclosure                              |
++------------------------+-------------------+----------------+----------------+
+| Application            | Server            | IoT            | Mobile         |
++------------------------+-------------------+----------------+----------------+
+| Impact                 |  Critical (5)     | Critical (5)   | Critical (5)   |
++------------------------+-------------------+----------------+----------------+
+| Likelihood             |  Medium (3)       | Medium (3)     | Medium (3)     |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating      |  High (15)        | High (15)      | High (15)      |
++------------------------+-------------------+----------------+----------------+
+| Mitigations            |   Clear the sensitive data from internal buffers as |
+|                        |   soon as they are not needed anymore.              |
++------------------------+-----------------------------------------------------+
+| Mitigations            | | Yes / Platform specific                           |
+| implemented?           |                                                     |
++------------------------+-----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID                     | 15                                                  |
++========================+=====================================================+
+| Threat                 | | **Improper handling of input data received over   |
+|                        |   a UART interface may allow an attacker to tamper  |
+|                        |   with TF-A execution environment.**                |
+|                        |                                                     |
+|                        | | The consequences of the attack depend on the      |
+|                        |   the exact usage of input data received over UART. |
+|                        |   Examples are injection of arbitrary data,         |
+|                        |   sensitive data tampering, influencing the         |
+|                        |   execution path, denial of service (if using       |
+|                        |   blocking I/O). This list may not be exhaustive.   |
++------------------------+-----------------------------------------------------+
+| Diagram Elements       | DF2, DF4, DF5                                       |
++------------------------+-----------------------------------------------------+
+| Affected TF-A          | BL1, BL2, BL31                                      |
+| Components             |                                                     |
++------------------------+-----------------------------------------------------+
+| Assets                 | Sensitive Data, Code Execution, Availability        |
++------------------------+-----------------------------------------------------+
+| Threat Agent           | NSCode, SecCode                                     |
++------------------------+-----------------------------------------------------+
+| Threat Type            | Tampering, Information Disclosure, Denial of        |
+|                        | service, Elevation of privilege.                    |
++------------------------+-------------------+----------------+----------------+
+| Application            | Server            | IoT            | Mobile         |
++------------------------+-------------------+----------------+----------------+
+| Impact                 |  Critical (5)     | Critical (5)   | Critical (5)   |
++------------------------+-------------------+----------------+----------------+
+| Likelihood             |  Critical (5)     | Critical (5)   | Critical (5)   |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating      |  Critical (25)    | Critical (25)  | Critical (25)  |
++------------------------+-------------------+----------------+----------------+
+| Mitigations            | | By default, the code to read input data from UART |
+|                        |   interfaces is disabled (see `ENABLE_CONSOLE_GETC` |
+|                        |   build option). It should only be enabled on a     |
+|                        |   need basis.                                       |
+|                        |                                                     |
+|                        | | Data received over UART interfaces should be      |
+|                        |   treated as untrusted data. As such, it should be  |
+|                        |   properly sanitized and handled with caution.      |
++------------------------+-----------------------------------------------------+
+| Mitigations            | | Platform specific.                                |
+| implemented?           |                                                     |
+|                        | | Generic code does not read any input data from    |
+|                        |   UART interface(s).                                |
++------------------------+-----------------------------------------------------+
+
+
+.. _Boot Firmware Threats:
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The boot firmware here refers to the boot ROM (BL1) and the trusted boot
+firmware (BL2). Typically it does not stay resident in memory and it is
+dismissed once execution has reached the runtime EL3 firmware (BL31). Thus, past
+that point in time, the threats below can no longer be exploited.
+
+Note, however, that this is not necessarily true on all platforms. Platform
+vendors should review these threats to make sure they cannot be exploited
+nonetheless once execution has reached the runtime EL3 firmware.
+
++------------------------+----------------------------------------------------+
+| ID                     | 01                                                 |
++========================+====================================================+
+| Threat                 | | **An attacker can mangle firmware images to      |
+|                        |   execute arbitrary code**                         |
+|                        |                                                    |
+|                        | | Some TF-A images are loaded from external        |
+|                        |   storage. It is possible for an attacker to access|
+|                        |   the external flash memory and change its contents|
+|                        |   physically, through the Rich OS, or using the    |
+|                        |   updating mechanism to modify the non-volatile    |
+|                        |   images to execute arbitrary code.                |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF4, DF5                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | BL2, BL31                                          |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Code Execution                                     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | PhysicalAccess, NSCode, SecCode                    |
++------------------------+----------------------------------------------------+
+| Threat Type            | Tampering, Elevation of Privilege                  |
++------------------------+------------------+-----------------+---------------+
+| Application            | Server           | IoT             | Mobile        |
++------------------------+------------------+-----------------+---------------+
+| Impact                 | Critical (5)     | Critical (5)    | Critical (5)  |
++------------------------+------------------+-----------------+---------------+
+| Likelihood             | Critical (5)     | Critical (5)    | Critical (5)  |
++------------------------+------------------+-----------------+---------------+
+| Total Risk Rating      | Critical (25)    | Critical (25)   | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| Mitigations            | | 1) Implement the `Trusted Board Boot (TBB)`_     |
+|                        |   feature which prevents malicious firmware from   |
+|                        |   running on the platform by authenticating all    |
+|                        |   firmware images.                                 |
+|                        |                                                    |
+|                        | | 2) Perform extra checks on unauthenticated data, |
+|                        |   such as FIP metadata, prior to use.              |
++------------------------+----------------------------------------------------+
+| Mitigations            | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented?           |   build option is set to 1.                        |
+|                        |                                                    |
+|                        | | 2) Yes.                                          |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 02                                                 |
++========================+====================================================+
+| Threat                 | | **An attacker may attempt to boot outdated,      |
+|                        |   potentially vulnerable firmware image**          |
+|                        |                                                    |
+|                        | | When updating firmware, an attacker may attempt  |
+|                        |   to rollback to an older version that has unfixed |
+|                        |   vulnerabilities.                                 |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF4, DF5                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | BL2, BL31                                          |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Code Execution                                     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | PhysicalAccess, NSCode, SecCode                    |
++------------------------+----------------------------------------------------+
+| Threat Type            | Tampering                                          |
++------------------------+------------------+-----------------+---------------+
+| Application            | Server           | IoT             | Mobile        |
++------------------------+------------------+-----------------+---------------+
+| Impact                 | Critical (5)     | Critical (5)    | Critical (5)  |
++------------------------+------------------+-----------------+---------------+
+| Likelihood             | Critical (5)     | Critical (5)    | Critical (5)  |
++------------------------+------------------+-----------------+---------------+
+| Total Risk Rating      | Critical (25)    | Critical (25)   | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| Mitigations            | Implement anti-rollback protection using           |
+|                        | non-volatile counters (NV counters) as required    |
+|                        | by `TBBR-Client specification`_.                   |
++------------------------+----------------------------------------------------+
+| Mitigations            | | Yes / Platform specific.                         |
+| implemented?           |                                                    |
+|                        | | After a firmware image is validated, the image   |
+|                        |   revision number taken from a certificate         |
+|                        |   extension field is compared with the             |
+|                        |   corresponding NV counter stored in hardware to   |
+|                        |   make sure the new counter value is larger than   |
+|                        |   the current counter value.                       |
+|                        |                                                    |
+|                        | | **Platforms must implement this protection using |
+|                        |   platform specific hardware NV counters.**        |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID                     | 03                                                    |
++========================+=======================================================+
+| Threat                 | | **An attacker can use Time-of-Check-Time-of-Use     |
+|                        |   (TOCTOU) attack to bypass image authentication      |
+|                        |   during the boot process**                           |
+|                        |                                                       |
+|                        | | Time-of-Check-Time-of-Use (TOCTOU) threats occur    |
+|                        |   when the security check is produced before the time |
+|                        |   the resource is accessed. If an attacker is sitting |
+|                        |   in the middle of the off-chip images, they could    |
+|                        |   change the binary containing executable code right  |
+|                        |   after the integrity and authentication check has    |
+|                        |   been performed.                                     |
++------------------------+-------------------------------------------------------+
+| Diagram Elements       | DF1                                                   |
++------------------------+-------------------------------------------------------+
+| Affected TF-A          | BL1, BL2                                              |
+| Components             |                                                       |
++------------------------+-------------------------------------------------------+
+| Assets                 | Code Execution, Sensitive Data                        |
++------------------------+-------------------------------------------------------+
+| Threat Agent           | PhysicalAccess                                        |
++------------------------+-------------------------------------------------------+
+| Threat Type            | Elevation of Privilege                                |
++------------------------+---------------------+-----------------+---------------+
+| Application            | Server              | IoT             | Mobile        |
++------------------------+---------------------+-----------------+---------------+
+| Impact                 | N/A                 | Critical (5)    | Critical (5)  |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood             | N/A                 | Medium (3)      | Medium (3)    |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating      | N/A                 | High (15)       | High (15)     |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations            | Copy image to on-chip memory before authenticating    |
+|                        | it.                                                   |
++------------------------+-------------------------------------------------------+
+| Mitigations            | | Platform specific.                                  |
+| implemented?           |                                                       |
+|                        | | The list of images to load and their location is    |
+|                        |   platform specific. Platforms are responsible for    |
+|                        |   arranging images to be loaded in on-chip memory.    |
++------------------------+-------------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID                     | 04                                                    |
++========================+=======================================================+
+| Threat                 | | **An attacker with physical access can execute      |
+|                        |   arbitrary image by bypassing the signature          |
+|                        |   verification stage using glitching techniques**     |
+|                        |                                                       |
+|                        | | Glitching (Fault injection) attacks attempt to put  |
+|                        |   a hardware into a undefined state by manipulating an|
+|                        |   environmental variable such as power supply.        |
+|                        |                                                       |
+|                        | | TF-A relies on a chain of trust that starts with the|
+|                        |   ROTPK, which is the key stored inside the chip and  |
+|                        |   the root of all validation processes. If an attacker|
+|                        |   can break this chain of trust, they could execute   |
+|                        |   arbitrary code on the device. This could be         |
+|                        |   achieved with physical access to the device by      |
+|                        |   attacking the normal execution flow of the          |
+|                        |   process using glitching techniques that target      |
+|                        |   points where the image is validated against the     |
+|                        |   signature.                                          |
++------------------------+-------------------------------------------------------+
+| Diagram Elements       | DF1                                                   |
++------------------------+-------------------------------------------------------+
+| Affected TF-A          | BL1, BL2                                              |
+| Components             |                                                       |
++------------------------+-------------------------------------------------------+
+| Assets                 | Code Execution                                        |
++------------------------+-------------------------------------------------------+
+| Threat Agent           | PhysicalAccess                                        |
++------------------------+-------------------------------------------------------+
+| Threat Type            | Tampering, Elevation of Privilege                     |
++------------------------+---------------------+-----------------+---------------+
+| Application            | Server              | IoT             | Mobile        |
++------------------------+---------------------+-----------------+---------------+
+| Impact                 | N/A                 | Critical (5)    | Critical (5)  |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood             | N/A                 | Medium (3)      | Medium (3)    |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating      | N/A                 | High (15)       | High (15)     |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations            | Mechanisms to detect clock glitch and power           |
+|                        | variations.                                           |
++------------------------+-------------------------------------------------------+
+| Mitigations            | | No.                                                 |
+| implemented?           |                                                       |
+|                        | | The most effective mitigation is adding glitching   |
+|                        |   detection and mitigation circuit at the hardware    |
+|                        |   level.                                              |
+|                        |                                                       |
+|                        | | However, software techniques, such as adding        |
+|                        |   redundant checks when performing conditional        |
+|                        |   branches that are security sensitive, can be used   |
+|                        |   to harden TF-A against such attacks.                |
+|                        |   **At the moment TF-A doesn't implement such         |
+|                        |   mitigations.**                                      |
++------------------------+-------------------------------------------------------+
+
+.. topic:: Measured Boot Threats (or lack of)
+
+ In the current Measured Boot design, BL1, BL2, and BL31, as well as the
+ secure world components, form the |SRTM|. Measurement data is currently
+ considered an asset to be protected against attack, and this is achieved
+ by storing them in the Secure Memory.
+ Beyond the measurements stored inside the TCG-compliant Event Log buffer,
+ there are no other assets to protect or threats to defend against that
+ could compromise |TF-A| execution environment's security.
+
+ There are general security assets and threats associated with remote/delegated
+ attestation. However, these are outside the |TF-A| security boundary and
+ should be dealt with by the appropriate agent in the platform/system.
+ Since current Measured Boot design does not use local attestation, there would
+ be no further assets to protect(like unsealed keys).
+
+ A limitation of the current Measured Boot design is that it is dependent upon
+ Secure Boot as implementation of Measured Boot does not extend measurements
+ into a discrete |TPM|, where they would be securely stored and protected
+ against tampering. This implies that if Secure-Boot is compromised, Measured
+ Boot may also be compromised.
+
+ Platforms must carefully evaluate the security of the default implementation
+ since the |SRTM| includes all secure world components.
+
+
+.. _Runtime Firmware Threats:
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
++------------------------+------------------------------------------------------+
+| ID                     | 07                                                   |
++========================+======================================================+
+| Threat                 | | **An attacker can perform a denial-of-service      |
+|                        |   attack by using a broken SMC call that causes the  |
+|                        |   system to reboot or enter into unknown state.**    |
+|                        |                                                      |
+|                        | | Secure and non-secure clients access TF-A services |
+|                        |   through SMC calls. Malicious code can attempt to   |
+|                        |   place the TF-A runtime into an inconsistent state  |
+|                        |   by calling unimplemented SMC call or by passing    |
+|                        |   invalid arguments.                                 |
++------------------------+------------------------------------------------------+
+| Diagram Elements       | DF4, DF5                                             |
++------------------------+------------------------------------------------------+
+| Affected TF-A          | BL31                                                 |
+| Components             |                                                      |
++------------------------+------------------------------------------------------+
+| Assets                 | Availability                                         |
++------------------------+------------------------------------------------------+
+| Threat Agent           | NSCode, SecCode                                      |
++------------------------+------------------------------------------------------+
+| Threat Type            | Denial of Service                                    |
++------------------------+-------------------+----------------+-----------------+
+| Application            | Server            | IoT            | Mobile          |
++------------------------+-------------------+----------------+-----------------+
+| Impact                 | Medium (3)        | Medium (3)     | Medium (3)      |
++------------------------+-------------------+----------------+-----------------+
+| Likelihood             | High (4)          | High (4)       | High (4)        |
++------------------------+-------------------+----------------+-----------------+
+| Total Risk Rating      | High (12)         | High (12)      | High (12)       |
++------------------------+-------------------+----------------+-----------------+
+| Mitigations            | Validate SMC function ids and arguments before using |
+|                        | them.                                                |
++------------------------+------------------------------------------------------+
+| Mitigations            | | Yes / Platform specific.                           |
+| implemented?           |                                                      |
+|                        | | For standard services, all input is validated.     |
+|                        |                                                      |
+|                        | | Platforms that implement SiP services must also    |
+|                        |   validate SMC call arguments.                       |
++------------------------+------------------------------------------------------+
+
+
++------------------------+------------------------------------------------------+
+| ID                     | 09                                                   |
++========================+======================================================+
+| Threat                 | | **Improperly handled SMC calls can leak register   |
+|                        |   contents**                                         |
+|                        |                                                      |
+|                        | | When switching between worlds, TF-A register state |
+|                        |   can leak to software in different security         |
+|                        |   contexts.                                          |
++------------------------+------------------------------------------------------+
+| Diagram Elements       | DF4, DF5                                             |
++------------------------+------------------------------------------------------+
+| Affected TF-A          | BL31                                                 |
+| Components             |                                                      |
++------------------------+------------------------------------------------------+
+| Assets                 | Sensitive Data                                       |
++------------------------+------------------------------------------------------+
+| Threat Agent           | NSCode, SecCode                                      |
++------------------------+------------------------------------------------------+
+| Threat Type            | Information Disclosure                               |
++------------------------+-------------------+----------------+-----------------+
+| Application            | Server            | IoT            | Mobile          |
++------------------------+-------------------+----------------+-----------------+
+| Impact                 | Medium (3)        | Medium (3)     | Medium (3)      |
++------------------------+-------------------+----------------+-----------------+
+| Likelihood             | High (4)          | High (4)       | High (4)        |
++------------------------+-------------------+----------------+-----------------+
+| Total Risk Rating      | High (12)         | High (12)      | High (12)       |
++------------------------+-------------------+----------------+-----------------+
+| Mitigations            | Save and restore registers when switching contexts.  |
++------------------------+------------------------------------------------------+
+| Mitigations            | | Yes.                                               |
+| implemented?           |                                                      |
+|                        | | This is the default behaviour in TF-A.             |
+|                        |   Build options are also provided to save/restore    |
+|                        |   additional registers such as floating-point        |
+|                        |   registers. These should be enabled if required.    |
++------------------------+------------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID                     | 10                                                  |
++========================+=====================================================+
+| Threat                 | | **SMC calls can leak sensitive information from   |
+|                        |   TF-A memory via microarchitectural side channels**|
+|                        |                                                     |
+|                        | | Microarchitectural side-channel attacks such as   |
+|                        |   `Spectre`_ can be used to leak data across        |
+|                        |   security boundaries. An attacker might attempt to |
+|                        |   use this kind of attack to leak sensitive         |
+|                        |   data from TF-A memory.                            |
++------------------------+-----------------------------------------------------+
+| Diagram Elements       | DF4, DF5                                            |
++------------------------+-----------------------------------------------------+
+| Affected TF-A          | BL31                                                |
+| Components             |                                                     |
++------------------------+-----------------------------------------------------+
+| Assets                 | Sensitive Data                                      |
++------------------------+-----------------------------------------------------+
+| Threat Agent           | SecCode, NSCode                                     |
++------------------------+-----------------------------------------------------+
+| Threat Type            | Information Disclosure                              |
++------------------------+-------------------+----------------+----------------+
+| Application            | Server            | IoT            | Mobile         |
++------------------------+-------------------+----------------+----------------+
+| Impact                 | Medium (3)        | Medium (3)     | Medium (3)     |
++------------------------+-------------------+----------------+----------------+
+| Likelihood             | Medium (3)        | Medium (3)     | Medium (3)     |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating      | Medium (9)        | Medium (9)     | Medium (9)     |
++------------------------+-------------------+----------------+----------------+
+| Mitigations            | Enable appropriate side-channel protections.        |
++------------------------+-----------------------------------------------------+
+| Mitigations            | | Yes / Platform specific.                          |
+| implemented?           |                                                     |
+|                        | | TF-A implements software mitigations for Spectre  |
+|                        |   type attacks as recommended by `Cache Speculation |
+|                        |   Side-channels`_ for the generic code.             |
+|                        |                                                     |
+|                        | | SiPs should implement similar mitigations for     |
+|                        |   code that is deemed to be vulnerable to such      |
+|                        |   attacks.                                          |
++------------------------+-----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID                     | 12                                                  |
++========================+=====================================================+
+| Threat                 | | **Incorrect configuration of Performance Monitor  |
+|                        |   Unit (PMU) counters can allow an attacker to      |
+|                        |   mount side-channel attacks using information      |
+|                        |   exposed by the counters**                         |
+|                        |                                                     |
+|                        | | Non-secure software can configure PMU registers   |
+|                        |   to count events at any exception level and in     |
+|                        |   both Secure and Non-secure states. This allows    |
+|                        |   a Non-secure software (or a lower-level Secure    |
+|                        |   software) to potentially carry out                |
+|                        |   side-channel timing attacks against TF-A.         |
++------------------------+-----------------------------------------------------+
+| Diagram Elements       | DF5, DF6                                            |
++------------------------+-----------------------------------------------------+
+| Affected TF-A          | BL31                                                |
+| Components             |                                                     |
++------------------------+-----------------------------------------------------+
+| Assets                 | Sensitive Data                                      |
++------------------------+-----------------------------------------------------+
+| Threat Agent           | NSCode                                              |
++------------------------+-----------------------------------------------------+
+| Threat Type            | Information Disclosure                              |
++------------------------+-------------------+----------------+----------------+
+| Application            | Server            | IoT            | Mobile         |
++------------------------+-------------------+----------------+----------------+
+| Impact                 | Medium (3)        | Medium (3)     | Medium (3)     |
++------------------------+-------------------+----------------+----------------+
+| Likelihood             | Low (2)           | Low (2)        | Low (2)        |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating      | Medium (6)        | Medium (6)     | Medium (6)     |
++------------------------+-------------------+----------------+----------------+
+| Mitigations            | Follow mitigation strategies as described in        |
+|                        | `Secure Development Guidelines`_.                   |
++------------------------+-----------------------------------------------------+
+| Mitigations            | | Yes / platform specific.                          |
+| implemented?           |                                                     |
+|                        | | General events and cycle counting in the Secure   |
+|                        |   world is prohibited by default when applicable.   |
+|                        |                                                     |
+|                        | | However, on some implementations (e.g. PMUv3)     |
+|                        |   Secure world event counting depends on external   |
+|                        |   debug interface signals, i.e. Secure world event  |
+|                        |   counting is enabled if external debug is enabled. |
+|                        |                                                     |
+|                        | | Configuration of debug signals is platform        |
+|                        |   specific, therefore platforms need to make sure   |
+|                        |   that external debug is disabled in production or  |
+|                        |   proper debug authentication is in place. This     |
+|                        |   should be the case if threat #06 is properly      |
+|                        |   mitigated.                                        |
++------------------------+-----------------------------------------------------+
+
+
+Threats to be Mitigated by an External Agent Outside of TF-A
+------------------------------------------------------------
+
++------------------------+-----------------------------------------------------+
+| ID                     | 14                                                  |
++========================+=====================================================+
+| Threat                 | | **Attacker wants to execute an arbitrary or       |
+|                        |   untrusted binary as the secure OS.**              |
+|                        |                                                     |
+|                        | | When the option OPTEE_ALLOW_SMC_LOAD is enabled,  |
+|                        |   this trusts the non-secure world up until the     |
+|                        |   point it issues the SMC call to load the Secure   |
+|                        |   BL32 payload. If a compromise occurs before the   |
+|                        |   SMC call is invoked, then arbitrary code execution|
+|                        |   in S-EL1 can occur or arbitrary memory in EL3 can |
+|                        |   be overwritten.                                   |
++------------------------+-----------------------------------------------------+
+| Diagram Elements       | DF5                                                 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A          | BL31, BL32                                          |
+| Components             |                                                     |
++------------------------+-----------------------------------------------------+
+| Assets                 | Code Execution, Sensitive Data                      |
++------------------------+-----------------------------------------------------+
+| Threat Agent           | NSCode                                              |
++------------------------+-----------------------------------------------------+
+| Threat Type            | Tampering, Information Disclosure,                  |
+|                        | Elevation of privilege                              |
++------------------------+-----------------+-----------------+-----------------+
+| Application            | Server          | IoT             | Mobile          |
++------------------------+-----------------+-----------------+-----------------+
+| Impact                 | Critical (5)    | Critical (5)    | Critical (5)    |
++------------------------+-----------------+-----------------+-----------------+
+| Likelihood             | High (4)        | High (4)        | High (4)        |
++------------------------+-----------------+-----------------+-----------------+
+| Total Risk Rating      | Critical (20)   | Critical (20)   | Critical (20)   |
++------------------------+-----------------+-----------------+-----------------+
+| Mitigations            | When enabling the option OPTEE_ALLOW_SMC_LOAD,      |
+|                        | the non-secure OS must be considered a closed       |
+|                        | platform up until the point the SMC can be invoked  |
+|                        | to load OP-TEE.                                     |
++------------------------+-----------------------------------------------------+
+| Mitigations            | | None in TF-A itself. This option is only used by  |
+| implemented?           |   ChromeOS currently which has other mechanisms to  |
+|                        |   to mitigate this threat which are described in    |
+|                        |   `OP-TEE Dispatcher`_.                             |
++------------------------+-----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021-2024, Arm Limited. All rights reserved.*
+
+
+.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
+.. _DEN0034: https://developer.arm.com/documentation/den0034/latest
+.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/
+.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html
+.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness
+.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
+.. _OP-TEE Dispatcher: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/components/spd/optee-dispatcher.rst
+.. _PSR Specification: https://developer.arm.com/documentation/den0106/0100
diff --git a/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst b/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst
new file mode 100644
index 0000000..af38ea3
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_arm_cca.rst
@@ -0,0 +1,225 @@
+Threat Model for TF-A with Arm CCA support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Introduction
+************
+
+This document provides a threat model of TF-A firmware for platforms with Arm
+Realm Management Extension (RME) support which implement Arm Confidential
+Compute Architecture (Arm CCA).
+
+Although it is a separate document, it references the :ref:`Generic Threat
+Model` in a number of places, as some of the contents is commonly applicable to
+TF-A with or without Arm CCA support.
+
+Target of Evaluation
+********************
+
+In this threat model, the target of evaluation is the Trusted Firmware for
+A-class Processors (TF-A) with RME support and Arm CCA support. This includes
+the boot ROM (BL1), the trusted boot firmware (BL2) and the runtime EL3 firmware
+(BL31).
+
+Assumptions
+===========
+
+We make the following assumptions:
+
+- :ref:`Realm Management Extension (RME)` is enabled on the platform.
+
+- Arm CCA Hardware Enforced Security (HES) is available on the platform, as
+  recommended by `Arm CCA security model`_:
+
+    *[R0004] Arm strongly recommends that all implementations of CCA utilize*
+    *hardware enforced security (CCA HES).*
+
+- All TF-A images run from on-chip memory. Data used by these images also live
+  in on-chip memory. This means TF-A is not vulnerable to an attacker that can
+  probe or tamper with off-chip memory.
+
+  These are requirements of the `Arm CCA security model`_:
+
+    *[R0147] Monitor code executes entirely from on-chip memory.*
+
+    *[R0149] Any monitor data that may affect the CCA security guarantee, other*
+    *than GPT, is either held in on-chip memory, or in external memory but with*
+    *additional integrity protection.*
+
+  Note that this threat model hardens *[R0149]* requirement by forbidding to
+  hold data in external memory, even if it is integrity-protected - except for
+  GPT data.
+
+- TF-A BL1 image is immutable and thus implicitly trusted. It runs from
+  read-only memory or write-protected memory. This could be on-chip ROM, on-chip
+  OTP, locked on-chip flash, or write-protected on-chip RAM for example.
+
+  This is a requirement of the `Arm CCA security model`_:
+
+    *[R0158] Arm recommends that all initial boot code is immutable on a*
+    *secured system.*
+
+    *[R0050] If all or part of initial boot code is instantiated in on-chip*
+    *memory then other trusted subsystems or application PE cannot modify that*
+    *code before it has been executed.*
+
+- Trusted boot and measured boot are enabled. This means an attacker can't boot
+  arbitrary images that are not approved by platform providers.
+
+  These are requirements of the `Arm CCA security model`_:
+
+    *[R0048] A secured system can only load authorized CCA firmware.*
+
+    *[R0079] All Monitor firmware loaded by PE initial boot is measured and*
+    *verified as outlined in Verified boot.*
+
+- No experimental features are enabled. These are typically incomplete features,
+  which need more time to stabilize. Thus, we do not consider threats that may
+  come from them. It is not recommended to use these features in production
+  builds.
+
+Data Flow Diagram
+=================
+
+Figure 1 shows a high-level data flow diagram for TF-A. The diagram shows a
+model of the different components of a TF-A-based system and their interactions
+with TF-A. A description of each diagram element is given on Table 1. On the
+diagram, the red broken lines indicate trust boundaries. Components outside of
+the broken lines are considered untrusted by TF-A.
+
+.. uml:: ../../resources/diagrams/plantuml/tfa_arm_cca_dfd.puml
+  :caption: Figure 1: Data Flow Diagram
+
+.. table:: Table 1: Data Flow Diagram Description
+
+  +-----------------+--------------------------------------------------------+
+  | Diagram Element | Description                                            |
+  +=================+========================================================+
+  |       DF1       | | Refer to DF1 description in the                      |
+  |                 |   :ref:`Generic Threat Model`. Additionally TF-A       |
+  |                 |   loads realm images.                                  |
+  +-----------------+--------------------------------------------------------+
+  |     DF2-DF6     | | Refer to DF2-DF6 descriptions in the                 |
+  |                 |   :ref:`Generic Threat Model`.                         |
+  +-----------------+--------------------------------------------------------+
+  |       DF7       | | Boot images interact with Arm CCA HES to record boot |
+  |                 |   measurements and retrieve data used for AP images    |
+  |                 |   authentication.                                      |
+  |                 |                                                        |
+  |                 | | The runtime firmware interacts with Arm CCA HES to   |
+  |                 |   obtain sensitive attestation data for the realm      |
+  |                 |   world.                                               |
+  +-----------------+--------------------------------------------------------+
+  |       DF8       | | Realm world software (e.g. TF-RMM) interact with     |
+  |                 |   TF-A through SMC call interface and/or shared        |
+  |                 |   memory.                                              |
+  +-----------------+--------------------------------------------------------+
+
+Threat Analysis
+***************
+
+In this threat model, we use the same method to analyse threats as in the
+:ref:`Generic Threat Model`. This section only points out differences where
+applicable.
+
+- There is an additional threat agent: *RealmCode*. It takes the form of
+  malicious or faulty code running in the realm world, including R-EL2, R-EL1
+  and R-EL0 levels.
+
+- At this time we only consider the ``Server`` target environment. New threats
+  identified in this threat model will only be given a risk rating for this
+  environment. Other environments may be added in a future revision
+
+Threat Assessment
+=================
+
+General Threats for All Firmware Images
+---------------------------------------
+
+The following table analyses the :ref:`General Threats` in the context of this
+threat model. Only deltas are pointed out.
+
+  +----+-------------+-------------------------------------------------------+
+  | ID | Applicable? | Comments                                              |
+  +====+=============+=======================================================+
+  | 05 |     Yes     |                                                       |
+  +----+-------------+-------------------------------------------------------+
+  | 06 |     Yes     |                                                       |
+  +----+-------------+-------------------------------------------------------+
+  | 08 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 11 |     Yes     | | Misconfiguration of the Memory Management Unit      |
+  |    |             |   (MMU) may allow a **normal/secure/realm** world     |
+  |    |             |   software to access sensitive data, execute arbitrary|
+  |    |             |   code or access otherwise restricted HW interface.   |
+  |    |             |                                                       |
+  |    |             | | **Note that on RME systems, MMU configuration also  |
+  |    |             |   includes Granule Protection Tables (GPT) setup.**   |
+  |    |             |                                                       |
+  |    |             | | Additional diagram elements: DF4, DF7, DF8.         |
+  |    |             |                                                       |
+  |    |             | | Additional threat agents: SecCode, RealmCode.       |
+  +----+-------------+-------------------------------------------------------+
+  | 13 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 15 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context of
+this threat model. Only deltas are pointed out.
+
+  +----+-------------+-------------------------------------------------------+
+  | ID | Applicable? | Comments                                              |
+  +====+=============+=======================================================+
+  | 01 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 02 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 03 |     Yes     |                                                       |
+  +----+-------------+-------------------------------------------------------+
+  | 04 |     Yes     |                                                       |
+  +----+-------------+-------------------------------------------------------+
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
+The following table analyses the :ref:`Runtime Firmware Threats` in the context
+of this threat model. Only deltas are pointed out.
+
+  +----+-------------+-------------------------------------------------------+
+  | ID | Applicable? | Comments                                              |
+  +====+=============+=======================================================+
+  | 07 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 09 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 10 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 12 |     Yes     | Additional diagram element: DF8.                      |
+  |    |             |                                                       |
+  |    |             | Additional threat agent: RealmCode.                   |
+  +----+-------------+-------------------------------------------------------+
+  | 14 |     Yes     |                                                       |
+  +----+-------------+-------------------------------------------------------+
+
+*Copyright (c) 2023-2024, Arm Limited. All rights reserved.*
+
+.. _Arm CCA Security Model: https://developer.arm.com/documentation/DEN0096/A_a
diff --git a/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst b/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst
new file mode 100644
index 0000000..a2d6798
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_el3_spm.rst
@@ -0,0 +1,650 @@
+EL3 SPMC Threat Model
+*********************
+
+************
+Introduction
+************
+This document provides a threat model for the TF-A :ref:`EL3 Secure Partition Manager`
+(EL3 SPM) implementation. The EL3 SPM implementation is based on the
+`Arm Firmware Framework for Arm A-profile`_ specification.
+
+********************
+Target of Evaluation
+********************
+In this threat model, the target of evaluation is the ``Secure Partition Manager Core``
+component (SPMC) within the EL3 firmware.
+The monitor and SPMD at EL3 are covered by the :ref:`Generic TF-A threat model
+<threat_analysis>`.
+
+The scope for this threat model is:
+
+- The TF-A implementation for the EL3 SPMC
+- The implementation complies with the FF-A v1.1 specification.
+- Secure partition is statically provisioned at boot time.
+- Focus on the run-time part of the life-cycle (no specific emphasis on boot
+  time, factory firmware provisioning, firmware udpate etc.)
+- Not covering advanced or invasive physical attacks such as decapsulation,
+  FIB etc.
+
+Data Flow Diagram
+=================
+Figure 1 shows a high-level data flow diagram for the SPM split into an SPMD
+and SPMC component at EL3. The SPMD mostly acts as a relayer/pass-through between
+the normal world and the secure world. It is assumed to expose small attack surface.
+
+A description of each diagram element is given in Table 1. In the diagram, the
+red broken lines indicate trust boundaries.
+
+Components outside of the broken lines are considered untrusted.
+
+.. uml:: ../../resources/diagrams/plantuml/el3_spm_dfd.puml
+  :caption: Figure 1: EL3 SPMC Data Flow Diagram
+
+.. table:: Table 1: EL3 SPMC Data Flow Diagram Description
+
+  +---------------------+--------------------------------------------------------+
+  | Diagram Element     | Description                                            |
+  +=====================+========================================================+
+  | DF1                 | SP to SPMC communication. FF-A function invocation or  |
+  |                     | implementation-defined Hypervisor call.                |
+  |                     |                                                        |
+  |                     | Note:- To communicate with LSP, SP1 performs a direct  |
+  |                     | message request to SPMC targeting LSP as destination.  |
+  +---------------------+--------------------------------------------------------+
+  | DF2                 | SPMC to SPMD communication.                            |
+  +---------------------+--------------------------------------------------------+
+  | DF3                 | SPMD to NS forwarding.                                 |
+  +---------------------+--------------------------------------------------------+
+  | DF4                 | SPMC to LSP communication.                             |
+  |                     | NWd to LSP communication happens through SPMC.         |
+  |                     | LSP can send direct response SP1 or NWd through SPMC.  |
+  +---------------------+--------------------------------------------------------+
+  | DF5                 | HW control.                                            |
+  +---------------------+--------------------------------------------------------+
+  | DF6                 | Bootloader image loading.                              |
+  +---------------------+--------------------------------------------------------+
+  | DF7                 | External memory access.                                |
+  +---------------------+--------------------------------------------------------+
+
+
+***************
+Threat Analysis
+***************
+
+This threat model follows a similar methodology to the :ref:`Generic TF-A threat model
+<threat_analysis>`. The following sections define:
+
+- Trust boundaries
+- Assets
+- Theat agents
+- Threat types
+
+Trust boundaries
+================
+
+- Normal world is untrusted.
+- Secure world and normal world are separate trust boundaries.
+- EL3 monitor, SPMD and SPMC are trusted.
+- Bootloaders (in particular BL1/BL2 if using TF-A) and run-time BL31 are
+  implicitely trusted by the usage of trusted boot.
+- EL3 monitor, SPMD, SPMC do not trust SPs.
+
+Assets
+======
+
+The following assets are identified:
+
+- SPMC state.
+- SP state.
+- Information exchange between endpoints (partition messages).
+- SPMC secrets (e.g. pointer authentication key when enabled)
+- SP secrets (e.g. application keys).
+- Scheduling cycles.
+- Shared memory.
+
+Threat Agents
+=============
+
+The following threat agents are identified:
+
+- Non-secure endpoint (referred NS-Endpoint later): normal world client at
+  NS-EL2 (Hypervisor) or NS-EL1 (VM or OS kernel).
+- Secure endpoint (referred as S-Endpoint later): typically a secure partition.
+- Hardware attacks (non-invasive) requiring a physical access to the device,
+  such as bus probing or DRAM stress.
+
+Threat types
+============
+
+The following threat categories as exposed in the :ref:`Generic TF-A threat model
+<threat_analysis>`
+are re-used:
+
+- Spoofing
+- Tampering
+- Repudiation
+- Information disclosure
+- Denial of service
+- Elevation of privileges
+
+Similarly this threat model re-uses the same threat risk ratings. The risk
+analysis is evaluated based on the environment being ``Server`` or ``Mobile``.
+IOT is not evaluated as the EL3 SPMC is primarily meant for use in Client.
+
+Threat Assessment
+=================
+
+The following threats are identified by applying STRIDE analysis on each diagram
+element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| ID                     | 01                                                 |
++========================+====================================================+
+| Threat                 | **An endpoint impersonates the sender              |
+|                        | FF-A ID in a direct request/response invocation.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3, DF4                                 |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMD, SPMC                                         |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP state                                           |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Spoofing                                           |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |  Mobile                 |
++------------------------+--------------------------++------------------------+
+| Impact                 | Critical(5)              | Critical(5)             |
++------------------------+--------------------------++------------------------+
+| Likelihood             | Critical(5)              | Critical(5)             |
++------------------------+--------------------------++------------------------+
+| Total Risk Rating      | Critical(25)             | Critical(25)            |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | SPMC must be able to correctly identify an         |
+|                        | endpoint and enforce checks to disallow spoofing.  |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes.                                               |
+| implemented?           | The SPMC enforces checks in the direct message     |
+|                        | request/response interfaces such an endpoint cannot|
+|                        | spoof the origin and destination worlds (e.g. a NWd|
+|                        | originated message directed to the SWd cannot use a|
+|                        | SWd ID as the sender ID).                          |
+|                        | Also enforces check for direct response being sent |
+|                        | only to originator of request.                     |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 02                                                 |
++========================+====================================================+
+| Threat                 | **An endpoint impersonates the receiver            |
+|                        | FF-A ID in a direct request/response invocation.** |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3, DF4                                 |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMD, SPMC                                         |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP state                                           |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Spoofing, Denial of Service                        |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |  Mobile                 |
++------------------------+--------------------------++------------------------+
+| Impact                 | Critical(5)              | Critical(5)             |
++------------------------+--------------------------++------------------------+
+| Likelihood             | Critical(5)              | Critical(5)             |
++------------------------+--------------------------++------------------------+
+| Total Risk Rating      | Critical(25)             | Critical(25)            |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Validate if endpoind has permission to send        |
+|                        | request to other endpoint by implementation        |
+|                        | defined means.                                     |
++------------------------+----------------------------------------------------+
+| Mitigations            | Platform specific.                                 |
+| implemented?           |                                                    |
+|                        | The guidance below is left for a system integrator |
+|                        | to implement as necessary.                         |
+|                        |                                                    |
+|                        | Additionally a software component residing in the  |
+|                        | SPMC can be added for the purpose of direct        |
+|                        | request/response filtering.                        |
+|                        |                                                    |
+|                        | It can be configured with the list of known IDs    |
+|                        | and about which interaction can occur between one  |
+|                        | and another endpoint (e.g. which NWd endpoint ID   |
+|                        | sends a direct request to which SWd endpoint ID).  |
+|                        |                                                    |
+|                        | This component checks the sender/receiver fields   |
+|                        | for a legitimate communication between endpoints.  |
+|                        |                                                    |
+|                        | A similar component can exist in the OS kernel     |
+|                        | driver, or Hypervisor although it remains untrusted|
+|                        | by the SPMD/SPMC.                                  |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 03                                                 |
++========================+====================================================+
+| Threat                 | **Tampering with memory shared between an endpoint |
+|                        | and the SPMC.**                                    |
+|                        |                                                    |
+|                        | A malicious endpoint may attempt tampering with its|
+|                        | RX/TX buffer contents while the SPMC is processing |
+|                        | it (TOCTOU).                                       |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF3, DF7                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Shared memory, Information exchange                |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Tampering                                          |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |    Mobile               |
++------------------------+--------------------------+-------------------------+
+| Impact                 | High (4)                 | High (4)                |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | High (4)                 | High (4)                |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | High (16)                | High (16)               |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Validate all inputs, copy before use.              |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes. In context of FF-A v1.1 this is the case of   |
+| implemented?           | sharing the RX/TX buffer pair and usage in the     |
+|                        | PARTITION_INFO_GET or memory sharing primitives.   |
+|                        |                                                    |
+|                        | The SPMC copies the contents of the TX buffer      |
+|                        | to an internal temporary buffer before processing  |
+|                        | its contents. The SPMC implements hardened input   |
+|                        | validation on data transmitted through the TX      |
+|                        | buffer by an untrusted endpoint.                   |
+|                        |                                                    |
+|                        | The TF-A SPMC enforces                             |
+|                        | checks on data transmitted through RX/TX buffers.  |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 04                                                 |
++========================+====================================================+
+| Threat                 | **An endpoint may tamper with its own state or the |
+|                        | state of another endpoint.**                       |
+|                        |                                                    |
+|                        | A malicious endpoint may attempt violating:        |
+|                        |                                                    |
+|                        | - its own or another SP state by using an unusual  |
+|                        |   combination (or out-of-order) FF-A function      |
+|                        |   invocations.                                     |
+|                        |   This can also be an endpoint emitting FF-A       |
+|                        |   function invocations to another endpoint while   |
+|                        |   the latter in not in a state to receive it (e.g. |
+|                        |   SP sends a direct request to the normal world    |
+|                        |   early while the normal world is not booted yet). |
+|                        | - the SPMC state itself by employing unexpected    |
+|                        |   transitions in FF-A memory sharing, direct       |
+|                        |   requests and responses, or handling of interrupts|
+|                        |   This can be led by random stimuli injection or   |
+|                        |   fuzzing.                                         |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMD, SPMC                                         |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP state, SPMC state                               |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Tampering                                          |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | High (4)                 | High (4)                |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | High (12)                | High (12)               |
++------------------------+------------------+-----------------+---------------+
+| Mitigations            | Follow guidelines in FF-A v1.1 specification on    |
+|                        | state transitions (run-time model).                |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes. The TF-A SPMC is hardened to follow this      |
+| implemented?           | guidance.                                          |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 05                                                 |
++========================+====================================================+
+| Threat                 | **Replay fragments of past communication between   |
+|                        | endpoints.**                                       |
+|                        |                                                    |
+|                        | A malicious endpoint may replay a message exchange |
+|                        | that occurred between two legitimate endpoints as  |
+|                        | a matter of triggering a malfunction or extracting |
+|                        | secrets from the receiving endpoint. In particular |
+|                        | the memory sharing operation with fragmented       |
+|                        | messages between an endpoint and the SPMC may be   |
+|                        | replayed by a malicious agent as a matter of       |
+|                        | getting access or gaining permissions to a memory  |
+|                        | region which does not belong to this agent.        |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF2, DF3                                           |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Information exchange                               |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Repudiation                                        |
++------------------------+--------------------------+-------------------------+
+| Application            |     Server               |    Mobile               |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | High (4)                 | High (4)	              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | High (12)                | High (12)               |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Strict input validation and state tracking.        |
++------------------------+----------------------------------------------------+
+| Mitigations            | Platform specific.                                 |
+| implemented?           |                                                    |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 06                                                 |
++========================+====================================================+
+| Threat                 | **A malicious endpoint may attempt to extract data |
+|                        | or state information by the use of invalid or      |
+|                        | incorrect input arguments.**                       |
+|                        |                                                    |
+|                        | Lack of input parameter validation or side effects |
+|                        | of maliciously forged input parameters might affect|
+|                        | the SPMC.                                          |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMD, SPMC                                         |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP secrets, SPMC secrets, SP state, SPMC state     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Information discolure                              |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |  Mobile                 |
++------------------------+--------------------------+-------------------------+
+| Impact                 | High (4)                 | High (4)                |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | High (12)                | High (12)               |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | SPMC must be prepared to receive incorrect input   |
+|                        | data from secure partitions and reject them        |
+|                        | appropriately.                                     |
+|                        | The use of software (canaries) or hardware         |
+|                        | hardening techniques (XN, WXN, pointer             |
+|                        | authentication) helps detecting and stopping       |
+|                        | an exploitation early.                             |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes. The TF-A SPMC mitigates this threat by        |
+| implemented?           | implementing stack protector, pointer              |
+|                        | authentication, XN, WXN, security hardening        |
+|                        | techniques.                                        |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 07                                                 |
++========================+====================================================+
+| Threat                 | **A malicious endpoint may forge a direct message  |
+|                        | request such that it reveals the internal state of |
+|                        | another endpoint through the direct message        |
+|                        | response.**                                        |
+|                        |                                                    |
+|                        | The secure partition or SPMC replies to a partition|
+|                        | message by a direct message response with          |
+|                        | information which may reveal its internal state    |
+|                        | (e.g. partition message response outside of        |
+|                        | allowed bounds).                                   |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SPMC or SP state                                   |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Information discolure                              |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |  Mobile                 |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Low (2)                  | Low (2)	              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | Medium (6)               | Medium (6)              |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Follow FF-A specification about state transitions, |
+|                        | run time model, do input validation.               |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes. For the specific case of direct requests      |
+| implemented?           | targeting the SPMC, the latter is hardened to      |
+|                        | prevent its internal state or the state of an SP   |
+|                        | to be revealed through a direct message response.  |
+|                        | Further FF-A v1.1 guidance about run time models   |
+|                        | and partition states is followed.                  |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 08                                                 |
++========================+====================================================+
+| Threat                 | **Probing the FF-A communication between           |
+|                        | endpoints.**                                       |
+|                        |                                                    |
+|                        | SPMC and SPs are typically loaded to external      |
+|                        | memory (protected by a TrustZone memory            |
+|                        | controller). A malicious agent may use non invasive|
+|                        | methods to probe the external memory bus and       |
+|                        | extract the traffic between an SP and the SPMC or  |
+|                        | among SPs when shared buffers are held in external |
+|                        | memory.                                            |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF7                                                |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP/SPMC state, SP/SPMC secrets                     |
++------------------------+----------------------------------------------------+
+| Threat Agent           | Hardware attack                                    |
++------------------------+----------------------------------------------------+
+| Threat Type            | Information disclosure                             |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Low (2)                  | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | Medium (6)               | Medium (9)              |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Implement DRAM protection techniques using         |
+|                        | hardware countermeasures at platform or chip level.|
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Platform specific.                                 |
+| implemented?           |                                                    |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 09                                                 |
++========================+====================================================+
+| Threat                 | **A malicious agent may attempt revealing the SPMC |
+|                        | state or secrets by the use of software-based cache|
+|                        | side-channel attack techniques.**                  |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF7                                                |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SP or SPMC state                                   |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Information disclosure                             |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Low (2)                  | Low (2)                 |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | Medium (6)               | Medium (6)              |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | The SPMC may be hardened further with SW           |
+|                        | mitigations (e.g. speculation barriers) for the    |
+|                        | cases not covered in HW. Usage of hardened         |
+|                        | compilers and appropriate options, code inspection |
+|                        | are recommended ways to mitigate Spectre types of  |
+|                        | attacks.                                           |
++------------------------+----------------------------------------------------+
+| Mitigations            | No.                                                |
+| implemented?           |                                                    |
++------------------------+----------------------------------------------------+
+
+
++------------------------+----------------------------------------------------+
+| ID                     | 10                                                 |
++========================+====================================================+
+| Threat                 | **A malicious endpoint may attempt flooding the    |
+|                        | SPMC with requests targeting a service within an   |
+|                        | endpoint such that it denies another endpoint to   |
+|                        | access this service.**                             |
+|                        |                                                    |
+|                        | Similarly, the malicious endpoint may target a     |
+|                        | a service within an endpoint such that the latter  |
+|                        | is unable to request services from another         |
+|                        | endpoint.                                          |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | SPMC state, Scheduling cycles                      |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Denial of service                                  |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | Medium (9)               | Medium (9)              |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Bounding the time for operations to complete can   |
+|                        | be achieved by the usage of a trusted watchdog.    |
+|                        | Other quality of service monitoring can be achieved|
+|                        | in the SPMC such as counting a number of operations|
+|                        | in a limited timeframe.                            |
++------------------------+----------------------------------------------------+
+| Mitigations            | Platform specific.                                 |
+| implemented?           |                                                    |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 11                                                 |
++========================+====================================================+
+| Threat                 | **Denying a lender endpoint to make progress if    |
+|                        | borrower endpoint encountered a fatal exception.   |
+|                        | Denying a new sender endpoint to make progress     |
+|                        | if receiver encountered a fatal exception.**       |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 | Shared resources, Scheduling cycles.               |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Denial of service                                  |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | Medium (3)               | Medium (3)              |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | Medium (9)               | Medium (9)              |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | SPMC must be able to detect fatal error in SP and  |
+|                        | take ownership of shared resources. It should      |
+|                        | be able to relinquish the access to shared memory  |
+|                        | regions to allow lender to proceed.                |
+|                        | SPMC must return ABORTED if new direct requests are|
+|                        | targeted to SP which has had a fatal error.        |
++------------------------+----------------------------------------------------+
+| Mitigations            | Platform specific.                                 |
+| implemented?           |                                                    |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID                     | 12                                                 |
++========================+====================================================+
+| Threat                 | **A malicious endpoint may attempt to donate,      |
+|                        | share, lend, relinquish or reclaim unauthorized    |
+|                        | memory region.**                                   |
++------------------------+----------------------------------------------------+
+| Diagram Elements       | DF1, DF2, DF3                                      |
++------------------------+----------------------------------------------------+
+| Affected TF-A          | SPMC                                               |
+| Components             |                                                    |
++------------------------+----------------------------------------------------+
+| Assets                 |  SP secrets, SPMC secrets, SP state, SPMC state    |
++------------------------+----------------------------------------------------+
+| Threat Agent           | NS-Endpoint, S-Endpoint                            |
++------------------------+----------------------------------------------------+
+| Threat Type            | Elevation of Privilege                             |
++------------------------+--------------------------+-------------------------+
+| Application            |   Server                 |   Mobile                |
++------------------------+--------------------------+-------------------------+
+| Impact                 | High (4)                 | High   (4)              |
++------------------------+--------------------------+-------------------------+
+| Likelihood             | High (4)                 | High (4)                |
++------------------------+--------------------------+-------------------------+
+| Total Risk Rating      | High (16)                | High (16)               |
++------------------------+--------------------------+-------------------------+
+| Mitigations            | Follow FF-A specification guidelines               |
+|                        | on Memory management transactions.                 |
++------------------------+----------------------------------------------------+
+| Mitigations            | Yes. The SPMC tracks ownership and access state    |
+| implemented?           | for memory transactions appropriately, and         |
+|                        | validating the same for all operations.            |
+|                        | SPMC follows FF-A v1.1                             |
+|                        | guidance for memory transaction lifecycle.         |
++------------------------+----------------------------------------------------+
+
+---------------
+
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*
+
+.. _Arm Firmware Framework for Arm A-profile: https://developer.arm.com/docs/den0077/latest
+.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases
diff --git a/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst b/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst
new file mode 100644
index 0000000..0b71bf0
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_fvp_r.rst
@@ -0,0 +1,99 @@
+fvp_r-Platform Threat Model
+***************************
+
+************************
+Introduction
+************************
+This document provides a threat model for TF-A fvp_r platform.
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the fvp_r platform of Trusted
+Firmware for A-class Processors (TF-A).  The fvp_r platform provides limited
+support of AArch64 R-class Processors (v8-R64).
+
+This is a delta document, only pointing out differences from the general TF-A
+threat-model document, :ref:`Generic Threat Model`
+
+BL1 Only
+========
+The most fundamental difference between the threat model for the current fvp_r
+implementation compared to the general TF-A threat model, is that fvp_r is
+currently limited to BL1 only.  Any threats from the general TF-A threat model
+unrelated to BL1 are therefore not relevant to the fvp_r implementation.
+
+The fvp_r BL1 implementation directly loads a customer/partner-defined runtime
+system.  The threat model for that runtime system, being partner-defined, is
+out-of-scope for this threat-model.
+
+Relatedly, all exceptions, synchronous and asynchronous, are disabled during BL1
+execution.  So, any references to exceptions are not relevant.
+
+EL3 is Unsupported and All Secure
+=================================
+v8-R64 cores do not support EL3, and (essentially) all operation is defined as
+Secure-mode.  Therefore:
+
+    - Any threats regarding NS operation are not relevant.
+
+    - Any mentions of SMCs are also not relevant.
+
+    - Anything otherwise-relevant code running in EL3 is instead run in EL2.
+
+MPU instead of MMU
+==================
+v8-R64 cores, running in EL2, use an MPU for memory management, rather than an
+MMU.  The MPU in the fvp_r implementation is configured to function effectively
+identically with the MMU for the usual BL1 implementation.  There are
+memory-map differences, but the MPU configuration is functionally equivalent.
+
+No AArch32 Support
+==================
+Another substantial difference between v8-A and v8-R64 cores is that v8-R64 does
+not support AArch32.  However, this is not believed to have any threat-modeling
+ramifications.
+
+
+Threat Assessment
+=================
+For this section, please reference the Threat Assessment under the general TF-A
+threat-model document, :ref:`Generic Threat Model`
+
+The following threats from that document are still relevant to the fvp_r
+implementation:
+
+    - ID 01:  An attacker can mangle firmware images to execute arbitrary code.
+
+    - ID 03:  An attacker can use Time-of-Check-Time-of-Use (TOCTOU) attack to
+      bypass image authentication during the boot process.
+
+    - ID 04:  An attacker with physical access can execute arbitrary image by
+      bypassing the signature verification stage using clock- or power-glitching
+      techniques.
+
+    - ID 05:  Information leak via UART logs such as crashes
+
+    - ID 06:  An attacker can read sensitive data and execute arbitrary code
+      through the external debug and trace interface.
+
+    - ID 08:  Memory corruption due to memory overflows and lack of boundary
+      checking when accessing resources could allow an attacker to execute 
+      arbitrary code, modify some state variable to change the normal flow of
+      the program, or leak sensitive.
+
+    - ID 11:  Misconfiguration of the Memory Protection Unit (MPU) may allow
+      normal world software to access sensitive data or execute arbitrary code.
+      Arguably, MPUs having fewer memory regions, there may be a temptation to
+      share memory regions, making this a greater threat.  However, since the
+      fvp_r implementation is limited to BL1, since BL1's regions are fixed,
+      and since the MPU configuration is equivalent with that for the fvp
+      platform and others, this is not expected to be a concern.
+
+    - ID 15:  Improper handling of input data received over a UART interface may
+      allow an attacker to tamper with TF-A execution environment.
+
+
+--------------
+
+*Copyright (c) 2021-2024, Arm Limited. All rights reserved.*
diff --git a/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst b/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst
new file mode 100644
index 0000000..7b55c74
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_fw_update_and_recovery.rst
@@ -0,0 +1,103 @@
+Threat Model for TF-A with PSA FWU or TBBR FWU support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Introduction
+************
+
+This document provides a threat model of TF-A firmware for platforms with
+the feature PSA firmware update or TBBR firmware update or both enabled.
+To understand the design of the firmware update refer
+:ref:`Firmware Update (FWU)`.
+
+Although it is a separate document, it references the :ref:`Generic Threat
+Model` in a number of places, as some of the contents are applicable to this
+threat model.
+
+Target of Evaluation
+********************
+
+In this threat model, the target of evaluation is the Trusted Firmware for
+A-class Processors (TF-A) when PSA FWU support is enabled or TBBR FWU mode
+is enabled. This includes the boot ROM (BL1), the trusted boot firmware (BL2).
+
+Threat Assessment
+*****************
+
+For this section, please reference the Threat Assessment under the
+:ref:`Generic Threat Model`. Here only the differences are highlighted.
+
+PSA FWU
+*******
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context
+of this threat model. Only additional details are pointed out.
+
++----+-------------+-------------------------------------------------------+
+| ID | Applicable? | Comments                                              |
++====+=============+=======================================================+
+| 01 |     Yes     | | Attacker can use arbitrary images to update the     |
+|    |             |   system.                                             |
++----+-------------+-------------------------------------------------------+
+| 02 |     Yes     | | Attacker tries to update the system with the        |
+|    |             |   vulnerable/older firmware.                          |
++----+-------------+-------------------------------------------------------+
+| 03 |     Yes     |                                                       |
++----+-------------+-------------------------------------------------------+
+| 04 |     Yes     |                                                       |
++----+-------------+-------------------------------------------------------+
+
+
+Threats to be mitigated by platform design
+------------------------------------------
+
+PSA FWU is driven by metadata stored in non-volatile storage. This metadata
+is not cryptographically signed. Also, depending on the hardware design,
+it may be stored in untrusted storage, which makes it possible for software
+outside of TF-A security boundary or for a physical attacker to modify it
+in order to change the behaviour of the FWU process.
+
+Below we provide some possible FWU metadata corruption scenarios:
+
+1. The FWU metadata includes the firmware bank for booting; the attacker
+   tries to modify it to prevent the execution of the updated firmware.
+2. The FWU metadata features a field indicating the firmware's status, either
+   in trial run or accepted run. The attacker tries to manipulate this field,
+   ensuring the updated firmware consistently runs in trial mode, with the
+   intention of preventing the anti-rollback update.
+
+By design, no software mitigations exist to prevent this. The safeguarding
+of FWU metadata relies on the platform's hardware design to mitigate potential
+attacks on it, if this is a concern in the platform's threat model.
+For example, FWU metadata may be stored in secure storage under exclusive
+access from secure software, protecting it from physical, unauthenticated
+accesses and from non-secure software accesses.
+
+TBBR FWU - Firmware Recovery
+****************************
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The following table analyses the :ref:`Boot Firmware Threats` in the context
+of this threat model. Only additional details are pointed out.
+
++----+-------------+-------------------------------------------------------+
+| ID | Applicable? | Comments                                              |
++====+=============+=======================================================+
+| 01 |     Yes     | | Attacker can use arbitrary images to recover the    |
+|    |             |   system.                                             |
++----+-------------+-------------------------------------------------------+
+| 02 |     Yes     | | Attacker tries to recover the system with the       |
+|    |             |   vulnerable/older firmware.                          |
++----+-------------+-------------------------------------------------------+
+| 03 |     Yes     |                                                       |
++----+-------------+-------------------------------------------------------+
+| 04 |     Yes     |                                                       |
++----+-------------+-------------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2024, Arm Limited. All rights reserved.*
diff --git a/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst b/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst
new file mode 100644
index 0000000..025d2d9
--- /dev/null
+++ b/docs/threat_model/firmware_threat_model/threat_model_rss_interface.rst
@@ -0,0 +1,59 @@
+Threat Model for RSS - 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
+next to the Application Processor (AP).
+
+********************
+Target of Evaluation
+********************
+The scope of this threat model only includes the interface between the RSS 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
+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
+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
+
+.. table:: Table 1: TF-A - RSS data flow diagram
+
+  +-----------------+--------------------------------------------------------+
+  | Diagram Element | Description                                            |
+  +=================+========================================================+
+  |       DF7       | | Boot images interact with RSS 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.        |
+  +-----------------+--------------------------------------------------------+
+
+Threat Assessment
+=================
+For this section, please reference the Threat Assessment under the general TF-A
+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
+      allowed only for firmware running at EL3. Accidentally exposing this
+      interface to NSCode can allow malicious code to interact with RSS 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
+      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.
+
+--------------
+
+*Copyright (c) 2022-2024, Arm Limited. All rights reserved.*