diff --git a/docs/threat_models/TF-M-block-diagram.png b/docs/threat_models/TF-M-block-diagram.png
new file mode 100644
index 0000000..e5d0371
--- /dev/null
+++ b/docs/threat_models/TF-M-block-diagram.png
Binary files differ
diff --git a/docs/threat_models/generic_thread_model.rst b/docs/threat_models/generic_thread_model.rst
new file mode 100644
index 0000000..dbbf605
--- /dev/null
+++ b/docs/threat_models/generic_thread_model.rst
@@ -0,0 +1,1095 @@
+#######################################
+Trusted Firmware-M Generic Threat Model
+#######################################
+
+************
+Introduction
+************
+
+This document introduces a generic thread model of Trusted Firmware-M (TF-M).
+This generic thread model provides an overall analysis of TF-M implementation
+and identifies general threats and mitigation.
+
+.. note::
+
+  If you think a security vulnerability is found, please follow
+  Trustedfirmware.org [Security-Incident-Process]_ to contact TF-M security
+  team.
+
+Scope
+=====
+
+TF-M supports diverse models and topologies. It also implements multiple
+isolation levels. Each case may focus on different target of evaluation (TOE)
+and identify different assets and threats.
+TF-M implementation consists of several secure services, defined as
+Root of Trust (RoT) service. Those RoT services belong to diverse RoT
+(Application RoT or PSA RoT) and access different assets and hardware. Therefore
+each RoT service may require a dedicated threat model.
+
+The analysis on specific models, topologies or RoT services may be covered in
+dedicated thread model documents. Those threat models are out of the scope of
+this document.
+
+Methodology
+===========
+
+The threat modeling in this document follows the process listed below to
+build up the threat model.
+
+- Target of Evaluation (TOE)
+- Assets identification
+- Data Flow Diagram (DFD)
+- Threats Prioritization
+- Threats identification
+
+TOE is the entity on which threat modeling is performed. The logic behind this
+process is to firstly investigate the TOE which could be a system, solution or
+use case. This first step helps to identify the assets to be protected in TOE.
+
+According to TOE and assets, Trust Boundaries can be determined. The Data Flow
+Diagram (DFD) across Trust Boundaries is then defined to help identify the
+threats.
+
+Those threats should be prioritized based on a specific group of principals and
+metrics. The principals and metrics should also be specified.
+
+********************
+Target of Evaluation
+********************
+
+A typical TF-M system diagram from a high-level overview is shown below. TF-M is
+running in the Secure Processing Environment (SPE) and NS software is running in
+Non-secure Processing Environment (NSPE). For more details, please refer to
+Platform Security Architecture Firmware Framework for M (FF-M) [FF-M]_.
+
+.. figure:: TF-M-block-diagram.png
+
+The TOE in this general model is the SPE, including TF-M and other components
+running in SPE.
+
+The TOE can vary in different TF-M models, RoT services and usage scenarios.
+Refer to dedicated thread models for the specific TOE definitions.
+
+********************
+Asset identification
+********************
+
+In this threat model, assets include the general items listed below:
+
+- Hardware Root of Trust data, e.g.
+
+    - Hardware Unique Key (HUK)
+    - Root authentication key
+    - Other embedded root keys
+
+- Software RoT data, e.g.
+
+    - Secure Partition Manager (SPM) code and data
+    - Secure partition code and data
+    - NSPE data stored in SPE
+    - Data generated in SPE as requested by NSPE
+
+- Availability of entire RoT service
+
+- Secure logs, including event logs
+
+Assets may vary in different use cases and implementations. Additional assets
+can be defined in an actual usage scenario and a dedicated threat model.
+
+For example, in a network camera use case, the following data can be defined as
+assets too:
+
+- Certificate for connecting to cloud
+- Session keys for encryption/decryption in the communication with cloud
+- Keys to encrypt/decrypt the videos and photos
+
+*****************
+Data Flow Diagram
+*****************
+
+The Trust Boundary isolates SPE from NSPE, according to the TOE definition in
+`Target of Evaluation`_. The Trust Boundary mapped to block diagram is shown
+in the figure below. Other modules inside SPE stay in the same TOE as TF-M does.
+
+Valid Data flows across the Trust Boundary are also shown in the figure below.
+This thread model only focuses on the data flows related to TF-M.
+
+.. figure:: overall-DFD.png
+
+More details of data flows are listed below.
+
+.. _data-flow-table:
+
+.. table:: TF-M Data Flows between NSPE and SPE
+
+  +-----------+----------------------------------------------------------------+
+  | Data flow | Description                                                    |
+  +===========+================================================================+
+  | ``DF1``   | TF-M initializes NS entry and activates NSPE.                  |
+  |           |                                                                |
+  |           | - On single Armv8-M core platforms, TF-M will hand over the    |
+  |           |   control to Non-secure state.                                 |
+  |           | - On dual-cpu platforms, Secure core starts NS core booting.   |
+  +-----------+----------------------------------------------------------------+
+  | ``DF2``   | NSPE requests TF-M RoT services.                               |
+  |           |                                                                |
+  |           | - In TF-M Library model, NS invokes Secure Function calls      |
+  |           | - In TF-M IPC model, NS invokes PSA Client calls based on IPC  |
+  |           |   protocol defined in [FF-M]_.                                 |
+  |           |                                                                |
+  |           | In single Armv8-M core scenarios, SG instruction is executed   |
+  |           | in Non-secure Callable region to trigger a transition from     |
+  |           | Non-secure state to Secure state.                              |
+  |           |                                                                |
+  |           | On dual-cpu platforms, non-secure core sends PSA Client calls  |
+  |           | to secure core via mailbox.                                    |
+  +-----------+----------------------------------------------------------------+
+  | ``DF3``   | Secure Partitions fetch input data from NS and write back      |
+  |           | output data to NS.                                             |
+  |           |                                                                |
+  |           | In TF-M IPC model, as required in [FF-M]_, Secure Partitions   |
+  |           | should not directly access NSPE memory. Instead, RoT services  |
+  |           | relies on TF-M SPM to access NSPE memory.                      |
+  +-----------+----------------------------------------------------------------+
+  | ``DF4``   | TF-M returns RoT service results to NSPE after NS request to   |
+  |           | RoT service is completed.                                      |
+  |           |                                                                |
+  |           | In single Armv8-M core scenarios, it also trigger a transition |
+  |           | from Secure state back to Non-secure state.                    |
+  |           |                                                                |
+  |           | On dual-cpu platforms, secure core returns the result to       |
+  |           | non-secure core via mailbox.                                   |
+  +-----------+----------------------------------------------------------------+
+  | ``DF5``   | Non-secure interrupts preempt SPE execution in single Armv8-M  |
+  |           | core scenarios.                                                |
+  +-----------+----------------------------------------------------------------+
+  | ``DF6``   | Secure interrupts preempt NSPE execution in single Armv8-M     |
+  |           | core scenarios.                                                |
+  +-----------+----------------------------------------------------------------+
+
+.. note::
+
+  All the other data flows across the Trusted Boundary besides the valid ones
+  mentioned above should be prohibited by default.
+  Proper isolation must be configured to prevent NSPE directly accessing SPE.
+
+  Threats irrelevant to data flows in
+  :ref:`TF-M Data Flows between NSPE and SPE <data-flow-table>` may be specified
+  in `Miscellaneous threats`_.
+
+Data flows inside SPE (informative)
+===================================
+
+Since all the SPE components stay in the TOE within the same Trust Boundary in
+this threat model, the data flows between SPE components are not covered in this
+threat model. Instead, those data flows and corresponding threats will be
+identified in the dedicated threat model documents of TF-M RoT services and
+usage scenarios.
+
+Those data flows inside SPE include following examples:
+
+- Data flows between TF-M and BL2
+- Data flows between RoT services and SPM
+- Data flows between RoT services and corresponding secure hardware and assets,
+  such as secure storage device, crypto hardware accelerator and Hardware Unique
+  Key (HUK).
+
+*********************
+Threat identification
+*********************
+
+Threat priority
+===============
+
+Threat priority is indicated by the score calculated via Common Vulnerability
+Scoring System (CVSS) Version 3.1 [CVSS]_. The higher the threat scores, the
+greater severity the threat is with and the higher the priority is.
+
+CVSS scores can be mapped to qualitative severity ratings defined in CVSS 3.1
+specification [CVSS_SPEC]_. This threat model follows the same mapping between
+CVSS scores and threat priority rating.
+
+As a generic threat model, this document focuses on *Base Score* which reflects
+the constant and general severity of a threat according to its intrinsic
+characteristics.
+
+The *Impacted Component* defined in [CVSS_SPEC]_ refers to the assets listed in
+`Asset identification`_.
+
+Threats and mitigation list
+===========================
+
+This section lists generic threats and corresponding mitigation, based on the
+the analysis of data flows in `Data Flow Diagram`_.
+
+Threats are identified following ``STRIDE`` model. Please refer to [STRIDE]_ for
+more details.
+
+The field ``CVSS Score`` reflects the threat priority defined in
+`Threat priority`_. The field ``CVSS Vector String`` contains the textual
+representation of the CVSS metric values used to score the threat. Refer to
+[CVSS_SPEC]_ for more details of CVSS vector string.
+
+.. note::
+
+  A generic threat may have different behaviors and therefore require different
+  mitigation, in diverse TF-M models and usage scenarios.
+
+  This threat model document focuses on general analysis of the following
+  threats. For the details in a specific configuration and usage scenario,
+  please refer to the dedicated threat model document.
+
+NS entry initialization
+-----------------------
+
+This section identifies threats on ``DF1`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-NS-INIT-T-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-T-1**                                |
+  +---------------+------------------------------------------------------------+
+  | Description   | The NS image can be tampered by an attacker                |
+  +---------------+------------------------------------------------------------+
+  | Justification | An attack may tamper the NS image to inject malicious code |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | By default TF-M relies on MCUBoot to validate NS image.    |
+  |               | The validation of NS image integrity and authenticity is   |
+  |               | completed in secure boot before jumping to NS entry or     |
+  |               | booting up NS core.                                        |
+  |               | Refer to [SECURE-BOOT]_ for more details.                  |
+  |               |                                                            |
+  |               | The validation may vary in diverse vendor platforms        |
+  |               | specific Chain of Trust (CoT) implementation.              |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 3.5 (Low)                                                  |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-T-2**                                |
+  +---------------+------------------------------------------------------------+
+  | Description   | An attacker may replace the current NS image with an older |
+  |               | version.                                                   |
+  +---------------+------------------------------------------------------------+
+  | Justification | The attacker downgrades the NS image with an older version |
+  |               | which has been deprecated due to known security issues.    |
+  |               |                                                            |
+  |               | The older version image can pass the image signature       |
+  |               | validation and its vulnerabilities can be exploited by     |
+  |               | attackers.                                                 |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M relies on MCUBoot to perform anti-rollback            |
+  |               | protection.                                                |
+  |               |                                                            |
+  |               | TF-M defines a non-volatile counter API to support         |
+  |               | anti-rollback. Each platform must implement it using       |
+  |               | specific trusted hardware non-volatile counters.           |
+  |               | For more details, refer to [ROLLBACK-PROTECT]_.            |
+  |               |                                                            |
+  |               | The anti-rollback protection implementation can vary on    |
+  |               | diverse platforms.                                         |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 3.5 (Low)                                                  |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-T-I-1**                              |
+  +---------------+------------------------------------------------------------+
+  | Description   | If SPE doesn't complete isolation configuration before     |
+  |               | NSPE starts, NSPE can access secure regions which it is    |
+  |               | disallowed to.                                             |
+  +---------------+------------------------------------------------------------+
+  | Justification | Secure data can be tampered or disclosed if NSPE is        |
+  |               | activated and accesses secure regions before isolation     |
+  |               | configuration is completed by SPE.                         |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering/Information disclosure                           |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | SPE must complete and enable proper isolation to protect   |
+  |               | secure regions from being accessed by NSPE, before jumping |
+  |               | to NS entry or booting up NS core.                         |
+  |               |                                                            |
+  |               | TF-M executes isolation configuration at early stage of    |
+  |               | secure initialization before NS initialization starts.     |
+  |               |                                                            |
+  |               | On dual-cpu platform, platform specific initialization     |
+  |               | must halt NS core until isolation is completed, as defined |
+  |               | in [DUAL-CPU-BOOT]_.                                       |
+  |               |                                                            |
+  |               | TF-M defines isolation configuration HALs for platform     |
+  |               | implementation. The specific isolation configuration       |
+  |               | depends on platform specific implementation.               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 9.0 (Critical)                                             |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-T-I-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-T-I-2**                              |
+  +---------------+------------------------------------------------------------+
+  | Description   | If SPE doesn't complete isolation configuration before     |
+  |               | NSPE starts, NSPE can control devices or peripherals which |
+  |               | it is disallowed to.                                       |
+  +---------------+------------------------------------------------------------+
+  | Justification | On some platforms, devices and peripherals can be          |
+  |               | configured as Secure state in runtime. If security status  |
+  |               | configuration of those device and peripherals are not      |
+  |               | properly completed before NSPE starts, NSPE can control    |
+  |               | those device and peripherals and may be able to tamper     |
+  |               | data or access secure data.                                |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering/Information disclosure                           |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | SPE must complete and enable proper configuration and      |
+  |               | isolation to protect critical devices and peripherals from |
+  |               | being accessed by NSPE, before jumping to NS entry or      |
+  |               | booting up NS core.                                        |
+  |               |                                                            |
+  |               | TF-M executes isolation configuration of devices and       |
+  |               | peripherals at early stage of secure initialization before |
+  |               | NS initialization starts.                                  |
+  |               |                                                            |
+  |               | The specific isolation configuration depends on platform   |
+  |               | specific implementation.                                   |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 9.0 (Critical)                                             |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-I-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-I-2**                                |
+  +---------------+------------------------------------------------------------+
+  | Description   | If SPE leaves some SPE information in non-secure memory    |
+  |               | or shared registers when NSPE starts, NSPE may access      |
+  |               | those SPE information.                                     |
+  +---------------+------------------------------------------------------------+
+  | Justification | If NSPE can access those SPE information from shared       |
+  |               | registers or non-secure memory, secure information may be  |
+  |               | disclosed.                                                 |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | SPE must clean up the secure information from shared       |
+  |               | registers before NS starts.                                |
+  |               |                                                            |
+  |               | TF-M invalidates registers not banked before handing over  |
+  |               | the system to NSPE on single Armv8-M platform.             |
+  |               |                                                            |
+  |               | On dual-cpu platforms, shared registers are implementation |
+  |               | defined, such as Inter-Processor Communication registers.  |
+  |               | Dual-cpu platforms must not store any data which may       |
+  |               | disclose secure information in the shared registers.       |
+  |               |                                                            |
+  |               | SPE must avoid storing SPE information in non-secure       |
+  |               | memory.                                                    |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INIT-D-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INIT-D-1**                                |
+  +---------------+------------------------------------------------------------+
+  | Description   | An attacker may block NS to boot up                        |
+  +---------------+------------------------------------------------------------+
+  | Justification | An attacker may block NS to boot up, such as by corrupting |
+  |               | NS image, to stop the whole system from performing normal  |
+  |               | functionalities.                                           |
+  +---------------+------------------------------------------------------------+
+  | Category      | Denial of service                                          |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | No SPE information will be disclosed and TF-M won't be     |
+  |               | directly impacted.                                         |
+  |               |                                                            |
+  |               | It relies on NSPE and platform specific implementation to  |
+  |               | mitigate this threat. It is out of scope of this threat    |
+  |               | model.                                                     |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.0 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+NSPE requests TF-M secure service
+---------------------------------
+
+This section identifies threats on ``DF2`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-S-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-S-1**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may pretend as a secure client  |
+  |               | to access secure data which NSPE must not directly access. |
+  +---------------+------------------------------------------------------------+
+  | Justification | [FF-M]_ defines ``Client ID`` to distinguish clients which |
+  |               | request RoT services. Secure clients are assigned with     |
+  |               | positive IDs and non-secure clients are assigned with      |
+  |               | negative ones.                                             |
+  |               |                                                            |
+  |               | A malicious NS application may provide a positive          |
+  |               | ``Client ID`` to pretend as a secure client to access      |
+  |               | secure data.                                               |
+  +---------------+------------------------------------------------------------+
+  | Category      | Spoofing                                                   |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M checks the ``Client ID`` from NSPE. If the NS         |
+  |               | ``Client ID`` is not a valid one, TF-M will report this as |
+  |               | a security error.                                          |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 8.4 (High)                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-T-1**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | An attacker in NSPE may tamper the service request input   |
+  |               | or output vectors between check and use                    |
+  |               | (Time-Of-Check-to-Time-Of-Use (TOCTOU)).                   |
+  +---------------+------------------------------------------------------------+
+  | Justification | If SPE validates the content in input/output vectors       |
+  |               | locally in NSPE memory, an attacker in NSPE can have a     |
+  |               | chance to tamper the content after the validation          |
+  |               | successfully passes. Then SPE will provide RoT service     |
+  |               | according to the corrupted parameters and it may cause     |
+  |               | further security issues.                                   |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | In TF-M implementation, the validation of NS input/output  |
+  |               | vectors are only executed after those vectors are copied   |
+  |               | from NSPE into SPE. It prevents an attack from NSPE to     |
+  |               | tamper those parameters after validation in TF-M.          |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 7.8 (High)                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-T-2**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may request to tamper data      |
+  |               | belonging to SPE.                                          |
+  +---------------+------------------------------------------------------------+
+  | Justification | A malicious NS application may request SPE RoT services to |
+  |               | write malicious value to SPE data. The malicious NS        |
+  |               | application may try to tamper SPE assets, such as keys, or |
+  |               | modify configurations in SPE. The SPE data belongs to      |
+  |               | components in SPE and must not be accessed by NSPE.        |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M executes memory access check to all the RoT service   |
+  |               | requests. If a request doesn't have enough permission to   |
+  |               | access the target memory region, TF-M will refuse this     |
+  |               | request and assert a security error.                       |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 7.1 (High)                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-R-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-R-1**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A NS application may repudiate that it has requested       |
+  |               | services from a RoT service.                               |
+  +---------------+------------------------------------------------------------+
+  | Justification | A malicious NS application may call a RoT service to       |
+  |               | access critical data in SPE, which it is disallowed to,    |
+  |               | via a non-public vulnerability. It may refuse to admit     |
+  |               | that it has accessed that data.                            |
+  +---------------+------------------------------------------------------------+
+  | Category      | Repudiation                                                |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M implements an event logging secure service to record  |
+  |               | the critical events, such as the access to critical data.  |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 0.0 (None)                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-I-1**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may request to read data        |
+  |               | belonging to SPE.                                          |
+  +---------------+------------------------------------------------------------+
+  | Justification | A malicious NS application may request SPE RoT services to |
+  |               | copy SPE data to NS memory. The SPE data belongs to        |
+  |               | components in SPE and must not be disclosed to NSPE, such  |
+  |               | as root keys.                                              |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M executes memory access check to all the RoT service   |
+  |               | requests. If a request doesn't have enough permission to   |
+  |               | access the target memory region, TF-M will refuse this     |
+  |               | request and assert a security error.                       |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 7.1 (High)                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-T-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-T-I-1**                      |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may request to control secure   |
+  |               | device and peripherals, on which it doesn't have the       |
+  |               | permission.                                                |
+  +---------------+------------------------------------------------------------+
+  | Justification | A malicious NS application may request RoT services to     |
+  |               | control secure device and peripherals, on which it doesn't |
+  |               | have the permission.                                       |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering/Information disclose                             |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M performs client check to validate whether the client  |
+  |               | has the permission to access the secure device and         |
+  |               | peripherals.                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 9.0 (Critical)                                             |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-D-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-D-1**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A Malicious NS applications may frequently call secure     |
+  |               | services to block secure service requests from other NS    |
+  |               | applications.                                              |
+  +---------------+------------------------------------------------------------+
+  | Justification | TF-M runs on IoT devices with constrained resource. Even   |
+  |               | though multiple outstanding NS PSA Client calls can be     |
+  |               | supported in system, the number of NS PSA client calls     |
+  |               | served by TF-M simultaneously are still limited.           |
+  |               |                                                            |
+  |               | Therefore, if a malicious NS application or multiple       |
+  |               | malicious NS applications continue calling TF-M secure     |
+  |               | services frequently, it may block other NS applications to |
+  |               | request secure service from TF-M.                          |
+  +---------------+------------------------------------------------------------+
+  | Category      | Denial of service                                          |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M is unable to manage behavior of NS applications.      |
+  |               | Assets are not disclosed and TF-M is neither directly      |
+  |               | impacted in this threat.                                   |
+  |               |                                                            |
+  |               | It relies on NS OS to enhance scheduling policy and        |
+  |               | prevent a single NS application to occupy entire CPU time. |
+  |               | It is beyond the scope of this threat model.               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.0 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-REQUEST-SERVICE-D-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-REQUEST-SERVICE-D-2**                        |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may provide invalid NS memory   |
+  |               | addresses as the addresses of input and output data in RoT |
+  |               | service requests.                                          |
+  +---------------+------------------------------------------------------------+
+  | Justification | SPE may be unable to achieve full knowledge of NS memory   |
+  |               | mapping. SPE may fail to capture those invalid NS memory   |
+  |               | addresses during memory access check since those invalid   |
+  |               | addresses may not be included in isolation configuration.  |
+  |               |                                                            |
+  |               | In that case, SPE will access those invalid NS memory      |
+  |               | addresses later to read or write data. It may trigger a    |
+  |               | system error to crash the whole system immediately.        |
+  |               |                                                            |
+  |               | The malicious NS application may be blocked by NS MPU from |
+  |               | directly accessing that invalid NS memory address. But it  |
+  |               | may manipulate SPE to access that address instead.         |
+  +---------------+------------------------------------------------------------+
+  | Category      | Denial of service                                          |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M executes memory access check to the memory addresses  |
+  |               | in all the NS requests.                                    |
+  |               |                                                            |
+  |               | On single Armv8-M core platforms, TF-M invokes ``TT``      |
+  |               | instructions to execute memory address check. If a NS      |
+  |               | memory area is not matched in any valid SAU or MPU region, |
+  |               | it will be marked as invalid and any access permission is  |
+  |               | disallowed. Therefore, SPM will reject any NS request      |
+  |               | containing invalid NS memory addresses and reports it as   |
+  |               | as a security error.                                       |
+  |               |                                                            |
+  |               | On dual-core platforms, TF-M implements a default memory   |
+  |               | access check. If a NS memory area is not found in any      |
+  |               | memory region configured for isolation, it will be marked  |
+  |               | as invalid and therefore SPM will reject the corresponding |
+  |               | NS request. It will be reported as a security error.       |
+  |               |                                                            |
+  |               | Dual-core platforms may implement platform specific memory |
+  |               | check to replace the default one. It relies on platform    |
+  |               | specific implementation to capture invalid memory address. |
+  |               | It is out of the scope of this document.                   |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 3.2 (Low)                                                  |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+RoT services read and write NS data
+-----------------------------------
+
+This section identifies threats on ``DF3`` defined in `Data Flow Diagram`_.
+
+According to [FF-M]_, in TF-M IPC model, RoT services should rely on TF-M SPM to
+obtain NS input data and send response data back to NS memory.
+
+In Library model, RoT services directly read and write NS memory to simplify the
+implementation and decrease latency.
+
+.. _TFM-GENERIC-SECURE-SERVICE-RW-T-1:
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-T-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-SECURE-SERVICE-RW-T-1**                      |
+  +---------------+------------------------------------------------------------+
+  | Description   | An attacker may tamper NS input data while the RoT service |
+  |               | is processing those data.                                  |
+  +---------------+------------------------------------------------------------+
+  | Justification | A RoT service may access NS input data multiple times      |
+  |               | during its data processing. For example, it may validate   |
+  |               | or authenticate the NS input data before it performs       |
+  |               | further processing.                                        |
+  |               |                                                            |
+  |               | If the NS input data remains in NSPE memory during the RoT |
+  |               | service execution, an attacker may tamper the NS input     |
+  |               | data in NSPE memory after the validation passes.           |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | In TF-M IPC model, RoT services request SPM to read and    |
+  |               | write NS data. TF-M SPM follows [FF-M]_ to copy the NS     |
+  |               | input data into SPE memory region owned by the RoT         |
+  |               | service, before the RoT service processes the data.        |
+  |               | Therefore, the NS input data is protected during the RoT   |
+  |               | service execution from being tampered.                     |
+  |               |                                                            |
+  |               | In TF-M Library model, RoT services can directly access NS |
+  |               | memory. If a RoT service accesses NS input data multiple   |
+  |               | times during data processing, it is required to review and |
+  |               | confirm Library model implementation of the RoT service    |
+  |               | copies NS input data into SPE memory area before it        |
+  |               | processes the data.                                        |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 3.2 (Low)                                                  |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. _TFM-GENERIC-SECURE-SERVICE-RW-T-2:
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-T-2
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-SECURE-SERVICE-RW-T-2**                      |
+  +---------------+------------------------------------------------------------+
+  | Description   | A malicious NS application may embed secure memory         |
+  |               | addresses into a structure in RoT service request input    |
+  |               | vectors, to tamper secure memory which the NS application  |
+  |               | must not access.                                           |
+  +---------------+------------------------------------------------------------+
+  | Justification | [FF-M]_ limits the total number of input/output vectors to |
+  |               | 4. If a RoT service requires more input/output vectors, it |
+  |               | may define a parameter structure which embeds multiple     |
+  |               | input/output buffers addresses.                            |
+  |               |                                                            |
+  |               | However, as a potential security risk, a malicious NS      |
+  |               | application can put secure memory addresses into a valid   |
+  |               | parameter structure to bypass TF-M validation on those     |
+  |               | memory addresses.                                          |
+  |               |                                                            |
+  |               | The parameter structure can pass TF-M memory access check  |
+  |               | since itself is valid. However, if the RoT service parses  |
+  |               | the structure and directly write malicious data from NSPE  |
+  |               | to the secure memory addresses in parameter structure, the |
+  |               | secure data will be tampered.                              |
+  +---------------+------------------------------------------------------------+
+  | Category      | Tampering                                                  |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | It should be avoided to embed memory addresses into a      |
+  |               | single input/output vector. If more than 4 memory          |
+  |               | addresses are required in a RoT service request, it is     |
+  |               | recommended to split this request into two or multiple     |
+  |               | service calls and therefore each service call requires no  |
+  |               | more than 4 input/output vectors.                          |
+  |               |                                                            |
+  |               | In TF-M IPC model, RoT services request SPM to read and    |
+  |               | write NS data. SPM will validate the target addresses and  |
+  |               | can detect the invalid addresses to mitigate this threat.  |
+  |               |                                                            |
+  |               | In TF-M Library model, RoT services can directly access NS |
+  |               | memory. It is required to review and confirm Library model |
+  |               | implementation of RoT service request doesn't embed memory |
+  |               | addresses.                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 6.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-SECURE-SERVICE-RW-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-SECURE-SERVICE-RW-I-1**                      |
+  +---------------+------------------------------------------------------------+
+  | Description   | Similar to TFM-GENERIC-SECURE-SERVICE-RW-T-2_, a malicious |
+  |               | NS application can embed secure memory addresses in a      |
+  |               | parameter structure in RoT service request input vectors,  |
+  |               | to read secure data which the NS application must not      |
+  |               | access.                                                    |
+  +---------------+------------------------------------------------------------+
+  | Justification | Similar to the description in                              |
+  |               | TFM-GENERIC-SECURE-SERVICE-RW-T-2_, the secure memory      |
+  |               | addresses hidden in the RoT service input/output vector    |
+  |               | structure may bypass TF-M validation. Without a proper     |
+  |               | check, the RoT service may copy secure data to NSPE        |
+  |               | according to the secure memory addresses in structure,     |
+  |               | secure information can be disclosed.                       |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | It should be avoided to embed memory addresses into a      |
+  |               | single input/output vector. If more than 4 memory          |
+  |               | addresses are required in a RoT service request, it is     |
+  |               | recommended to split this request into two or multiple     |
+  |               | service calls and therefore each service call requires no  |
+  |               | more than 4 input/output vectors.                          |
+  |               |                                                            |
+  |               | In TF-M IPC model, RoT services request SPM to read and    |
+  |               | write NS data. SPM will validate the target addresses and  |
+  |               | can detect the invalid addresses to mitigate this threat.  |
+  |               |                                                            |
+  |               | In TF-M Library model, RoT services can directly access NS |
+  |               | memory. It is required to review and confirm Library model |
+  |               | implementation of RoT service request doesn't embed memory |
+  |               | addresses.                                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 6.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+TF-M returns secure service result
+----------------------------------
+
+This section identifies threats on ``DF4`` defined in `Data Flow Diagram`_.
+
+When RoT service completes the request from NSPE, TF-M returns the success or
+failure error code to NS application.
+
+In single Armv8-M core scenario, TF-M writes the return code value in the
+general purpose register and returns to Non-secure state.
+
+On dual-cpu platforms, TF-M writes the return code to NSPE mailbox message queue
+via mailbox.
+
+.. table:: TFM-GENERIC-RETURN-CODE-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-RETURN-CODE-I-1**                            |
+  +---------------+------------------------------------------------------------+
+  | Description   | SPE may leave secure data in the registers not banked      |
+  |               | after the SPE completes PSA Client calls and executes      |
+  |               | ``BXNS`` to switch Armv8-M back to Non-secure state.       |
+  +---------------+------------------------------------------------------------+
+  | Justification | If SPE doesn't clean up the secure data in registers not   |
+  |               | banked before switching into NSPE in Armv8-M core, NSPE    |
+  |               | can read the SPE context from those registers.             |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | In single Armv8-M core scenario, TF-M cleans general       |
+  |               | purpose registers not banked before switching into NSPE to |
+  |               | prevent NSPE probing secure context from the registers.    |
+  |               |                                                            |
+  |               | Current TF-M implementation doesn't support FPU in SPE.    |
+  |               | TF-M build will stop if FPU is enabled on platform.        |
+  |               | Therefore, FPU registers doesn't contain data that needs   |
+  |               | to be protected from NSPE.                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+NS interrupts preempts SPE execution
+------------------------------------
+
+This section identifies threats on ``DF5`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-NS-INTERRUPT-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INTERRUPT-I-1**                           |
+  +---------------+------------------------------------------------------------+
+  | Description   | Shared registers may contain secure data when NS           |
+  |               | interrupts occur.                                          |
+  +---------------+------------------------------------------------------------+
+  | Justification | The secure data in shared registers should be cleaned up   |
+  |               | before NSPE can access shared registers. Otherwise, secure |
+  |               | data leakage may occur.                                    |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | In single Armv8-M core scenario, Armv8-M architecture      |
+  |               | automatically cleans up the registers not banked before    |
+  |               | switching to Non-secure state while taking NS interrupts.  |
+  |               |                                                            |
+  |               | Current TF-M implementation doesn't support FPU in SPE.    |
+  |               | TF-M build will stop if FPU is enabled on platform.        |
+  |               | Therefore, FPU registers doesn't contain data that needs   |
+  |               | to be protected from NSPE.                                 |
+  |               |                                                            |
+  |               | On dual-cpu platforms, shared registers are implementation |
+  |               | defined, such as Inter-Processor Communication registers.  |
+  |               | Dual-cpu platforms must not store any data which may       |
+  |               | disclose secure information in the shared registers.       |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+.. table:: TFM-GENERIC-NS-INTERRUPT-D-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-NS-INTERRUPT-D-1**                           |
+  +---------------+------------------------------------------------------------+
+  | Description   | An attacker may trigger spurious NS interrupts frequently  |
+  |               | to block SPE execution.                                    |
+  +---------------+------------------------------------------------------------+
+  | Justification | In single Armv8-M core scenario, an attacker may inject a  |
+  |               | malicious NS application or hijack a NS hardware to        |
+  |               | frequently trigger spurious NS interrupts to keep          |
+  |               | preempting SPE and block SPE to perform normal secure      |
+  |               | execution.                                                 |
+  +---------------+------------------------------------------------------------+
+  | Category      | Denial of service                                          |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | It is out of scope of TF-M.                                |
+  |               |                                                            |
+  |               | Assets protected by TF-M won't be leaked. TF-M won't be    |
+  |               | directly impacted.                                         |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.0 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+Secure interrupts preempts NSPE execution
+-----------------------------------------
+
+This section identifies threats on ``DF6`` defined in `Data Flow Diagram`_.
+
+.. table:: TFM-GENERIC-S-INTERRUPT-I-1
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-S-INTERRUPT-I-1**                            |
+  +---------------+------------------------------------------------------------+
+  | Description   | Shared registers may contain secure data when Armv8-M core |
+  |               | switches back to Non-secure state on Secure interrupt      |
+  |               | return.                                                    |
+  +---------------+------------------------------------------------------------+
+  | Justification | Armv8-M architecture doesn't automatically clean up shared |
+  |               | registers while returning to Non-secure state during       |
+  |               | Secure interrupt return.                                   |
+  |               |                                                            |
+  |               | If SPE leaves critical data in the Armv8-M registers not   |
+  |               | banked, NSPE can read secure context from those registers  |
+  |               | and secure data leakage may occur.                         |
+  +---------------+------------------------------------------------------------+
+  | Category      | Information disclosure                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M saves NPSE context in general purpose register R4~R11 |
+  |               | into secure stack during secure interrupt entry.           |
+  |               | After secure interrupt handling completes, TF-M unstacks   |
+  |               | NSPE context from secure stack to overwrite secure context |
+  |               | in R4~R11 before secure interrupt return.                  |
+  |               |                                                            |
+  |               | Armv8-M architecture will automatically unstack NSPE       |
+  |               | context from non-secure stack to overwrite other registers |
+  |               | not banked, such as R0~R3 and R12, during secure interrupt |
+  |               | return, before NSPE software can access those registers.   |
+  |               |                                                            |
+  |               | Current TF-M implementation doesn't support FPU in SPE.    |
+  |               | TF-M build will stop if FPU is enabled on platform.        |
+  |               | Therefore, FPU registers doesn't contain data that needs   |
+  |               | to be protected from NSPE.                                 |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 4.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+Miscellaneous threats
+---------------------
+
+This section collects threats irrelevant to the valid TF-M data flows shown
+above.
+
+.. table:: TFM-GENERIC-STACK-SEAL
+  :widths: 10 50
+
+  +---------------+------------------------------------------------------------+
+  | Index         | **TFM-GENERIC-STACK_SEAL**                                 |
+  +---------------+------------------------------------------------------------+
+  | Description   | Armv8-M processor Secure software Stack Sealing            |
+  |               | vulnerability.                                             |
+  +---------------+------------------------------------------------------------+
+  | Justification | On Armv8-M based processors with TrustZone, if Secure      |
+  |               | software does not properly manage the Secure stacks when   |
+  |               | the stacks are created, or when performing non-standard    |
+  |               | transitioning between states or modes, for example,        |
+  |               | creating a fake exception return stack frame to            |
+  |               | de-privilege an interrupt, it is possible for Non-secure   |
+  |               | world software to manipulate the Secure Stacks, and        |
+  |               | potentially influence Secure control flow.                 |
+  |               |                                                            |
+  |               | Refer to [STACK-SEAL]_ for details.                        |
+  +---------------+------------------------------------------------------------+
+  | Category      | Elevation of privilege                                     |
+  +---------------+------------------------------------------------------------+
+  | Mitigation    | TF-M has implemented common mitigation against stack seal  |
+  |               | vulnerability.                                             |
+  |               |                                                            |
+  |               | Refer to [ADVISORY-TFMV-1]_ for details on analysis and    |
+  |               | mitigation in TF-M.                                        |
+  +---------------+------------------------------------------------------------+
+  | CVSS Score    | 5.3 (Medium)                                               |
+  +---------------+------------------------------------------------------------+
+  | CVSS Vector   | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L               |
+  | String        |                                                            |
+  +---------------+------------------------------------------------------------+
+
+***************
+Version control
+***************
+
+.. table:: Version control
+
+  +---------+--------------------------------------------------+---------------+
+  | Version | Description                                      | TF-M version  |
+  +=========+==================================================+===============+
+  | v0.1    | Initial draft                                    | TF-M v1.1     |
+  +---------+--------------------------------------------------+---------------+
+
+*********
+Reference
+*********
+
+.. [Security-Incident-Process] `Security Incident Process <https://developer.trustedfirmware.org/w/collaboration/security_center/reporting/>`_
+
+.. [FF-M] `Arm® Platform Security Architecture Firmware Framework 1.0 <https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4>`_
+
+.. [DUAL-CPU-BOOT] :doc:`Booting a dual core system </docs/design_documents/dual-cpu/booting_a_dual_core_system>`
+
+.. [CVSS] `Common Vulnerability Scoring System Version 3.1 Calculator <https://www.first.org/cvss/calculator/3.1>`_
+
+.. [CVSS_SPEC] `CVSS v3.1 Specification Document <https://www.first.org/cvss/v3-1/cvss-v31-specification_r1.pdf>`_
+
+.. [STRIDE] `The STRIDE Threat Model <https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=MSDN>`_
+
+.. [SECURE-BOOT] :doc:`Secure boot </docs/getting_started/tfm_secure_boot>`
+
+.. [ROLLBACK-PROTECT] :doc:`Rollback protection in TF-M secure boot </docs/design_documents/secure_boot_rollback_protection>`
+
+.. [STACK-SEAL] `Armv8-M processor Secure software Stack Sealing vulnerability <https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing>`_
+
+.. [ADVISORY-TFMV-1] :doc:`Advisory TFMV-1 </docs/reference/security_advisories/stack_seal_vulnerability>`
+
+--------------------
+
+*Copyright (c) 2020 Arm Limited. All Rights Reserved.*
diff --git a/docs/threat_models/index.rst b/docs/threat_models/index.rst
new file mode 100644
index 0000000..227d4d4
--- /dev/null
+++ b/docs/threat_models/index.rst
@@ -0,0 +1,12 @@
+Threat Models
+=============
+
+.. toctree::
+    :maxdepth: 1
+    :glob:
+
+    *
+
+--------------
+
+*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/threat_models/overall-DFD.png b/docs/threat_models/overall-DFD.png
new file mode 100644
index 0000000..39cf4c8
--- /dev/null
+++ b/docs/threat_models/overall-DFD.png
Binary files differ