diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst
index c75d7ad..e177952 100644
--- a/docs/about/maintainers.rst
+++ b/docs/about/maintainers.rst
@@ -33,8 +33,8 @@
     :email: `Tamas.Ban@arm.com <Tamas.Ban@arm.com>`__
     :github: `tamban01 <https://github.com/tamban01>`__
 
-Secure Storage
-~~~~~~~~~~~~~~
+Secure Storage (ITS & PS)
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Jamie Fox
     :email: `jamie.fox@arm.com <jamie.fox@arm.com>`__
diff --git a/docs/design_documents/sst_key_management.rst b/docs/design_documents/ps_key_management.rst
similarity index 78%
rename from docs/design_documents/sst_key_management.rst
rename to docs/design_documents/ps_key_management.rst
index 0f617e8..80a39be 100644
--- a/docs/design_documents/sst_key_management.rst
+++ b/docs/design_documents/ps_key_management.rst
@@ -1,6 +1,6 @@
-=====================================
-Secure Storage service key management
-=====================================
+========================================
+Protected Storage service key management
+========================================
 
 :Author: Jamie Fox
 :Organization: Arm Limited
@@ -21,13 +21,13 @@
 128 bits of entropy (and a 128 bit data size), and be accessible only to Trusted
 code or Trusted hardware that acts on behalf of Trusted code. [TBSA-M]_
 
-In the current implementation, the Secure Storage (SST) service reads the HUK
+In the current implementation, the Protected Storage (PS) service reads the HUK
 directly and imports it into the Crypto partition for further use. This has
 multiple drawbacks:
 
-- If there were a flaw in SST that allowed an attacker to obtain its key, then
+- If there were a flaw in PS that allowed an attacker to obtain its key, then
   the HUK would be exposed, and so the attacker would be able to decrypt not
-  just secure storage but also anything else encrypted with the HUK or a key
+  just protected storage but also anything else encrypted with the HUK or a key
   derived from the HUK.
 - Using the same key for two or more different cryptographic algorithms may
   reduce the security provided by one or more of them.
@@ -38,21 +38,21 @@
 
 Proposal
 ========
-Each time the system boots, SST will request that the Crypto service uses a key
+Each time the system boots, PS will request that the Crypto service uses a key
 derivation function (KDF) to derive a storage key from the HUK. The storage key
 could be kept in on-chip volatile memory private to the Crypto partition, or it
-could remain inside a secure element. Either way it will not be returned to SST.
+could remain inside a secure element. Either way it will not be returned to PS.
 
-For each call to the PSA Protected Storage APIs, SST will make requests to the
+For each call to the PSA Protected Storage APIs, PS will make requests to the
 Crypto service to perform AEAD encryption and/or decryption operations using the
 storage key (providing a fresh nonce for each encryption).
 
-At no point will SST access the key material itself, only referring to the HUK
+At no point will PS access the key material itself, only referring to the HUK
 and storage key by their handles in the Crypto service.
 
 Key derivation
 ==============
-SST will make key derivation requests to the Crypto service with calls to the
+PS will make key derivation requests to the Crypto service with calls to the
 PSA Crypto APIs. In order to derive the storage key, the following calls will be
 made::
 
@@ -62,33 +62,33 @@
                  &huk_key_handle)
 
     /* Set up a key derivation operation with the HUK as the input key */
-    psa_key_derivation(&sst_key_generator,
+    psa_key_derivation(&ps_key_generator,
                        huk_key_handle,
                        TFM_CRYPTO_ALG_HUK_DERIVATION,
-                       SST_KEY_SALT, SST_KEY_SALT_LEN_BYTES,
-                       SST_KEY_LABEL, SST_KEY_LABEL_LEN_BYTES,
-                       SST_KEY_LEN_BYTES)
+                       PS_KEY_SALT, PS_KEY_SALT_LEN_BYTES,
+                       PS_KEY_LABEL, PS_KEY_LABEL_LEN_BYTES,
+                       PS_KEY_LEN_BYTES)
 
     /* Create the storage key from the key generator */
-    psa_generator_import_key(sst_key_handle,
-                             SST_KEY_TYPE,
-                             PSA_BYTES_TO_BITS(SST_KEY_LEN_BYTES),
-                             &sst_key_generator)
+    psa_generator_import_key(ps_key_handle,
+                             PS_KEY_TYPE,
+                             PSA_BYTES_TO_BITS(PS_KEY_LEN_BYTES),
+                             &ps_key_generator)
 
 .. note:: ``TFM_CRYPTO_KEY_ID_HUK`` is a PSA Crypto key ID that is assumed in
           this design to identify the hardware unique key.
 
-          ``sst_key_handle`` is a PSA Crypto key handle to a volatile key, set
+          ``ps_key_handle`` is a PSA Crypto key handle to a volatile key, set
           up in the normal way. After the call to ``psa_generator_import_key``,
           it contains the storage key.
 
-          ``SST_KEY_SALT`` can be ``NULL``, as it is only used in the 'extract'
+          ``PS_KEY_SALT`` can be ``NULL``, as it is only used in the 'extract'
           step of HKDF, which is redundant when the input key material is a
           cryptographically strong key. [RFC5869]_ It must be constant so that
           the same key can be derived each boot, to decrypt previously-stored
           data.
 
-          ``SST_KEY_LABEL`` can be any string that is independent of the input
+          ``PS_KEY_LABEL`` can be any string that is independent of the input
           key material and different to the label used in any other derivation
           from the same input key. It prevents two different contexts from
           deriving the same output key from the same input key.
@@ -109,7 +109,7 @@
   case here).
 - The trade-off is that HKDF is only suitable when the input key material has at
   least as much entropy as required for the output key material. But this is the
-  case here, as the HUK has 128 bits of entropy, the same as required by SST.
+  case here, as the HUK has 128 bits of entropy, the same as required by PS.
 - HKDF is standardised in RFC 5869 [RFC5869]_ and its security has been formally
   analysed. [HKDF]_
 - It is supported by the TF-M Crypto service.
@@ -119,8 +119,8 @@
 Crypto. This narrows it down to just the SHA-2 family. Of the hash functions in
 the family, SHA-256 is the simplest and provides more than enough output length.
 
-Keeping the storage key private to SST
---------------------------------------
+Keeping the storage key private to PS
+-------------------------------------
 The salt and label fields are not generally secret, so an Application RoT
 service could request the Crypto service to derive the same storage key from the
 HUK, which violates isolation between Application RoT partitions to some extent.
@@ -128,10 +128,10 @@
 
 - Only PSA RoT partitions can request Crypto to derive keys from the HUK.
 
-  - But then either SST has to be in the PSA RoT or request a service in the PSA
+  - But then either PS has to be in the PSA RoT or request a service in the PSA
     RoT to do the derivation on its behalf.
 
-- SST has a secret (pseudo)random salt, accessible only to it, that it uses to
+- PS has a secret (pseudo)random salt, accessible only to it, that it uses to
   derive the storage key.
 
   - Where would this salt be stored? It cannot be generated fresh each boot
@@ -150,13 +150,13 @@
 
 Key use
 =======
-To encrypt and decrypt data, SST will call the PSA Crypto AEAD APIs in the same
-way as the current implementation, but ``sst_key_handle`` will refer to the
+To encrypt and decrypt data, PS will call the PSA Crypto AEAD APIs in the same
+way as the current implementation, but ``ps_key_handle`` will refer to the
 storage key, rather than the imported HUK. For each encryption operation, the
 following call is made (and analogously for decryption)::
 
-    psa_aead_encrypt(sst_key_handle, SST_CRYPTO_ALG,
-                     crypto->ref.iv, SST_IV_LEN_BYTES,
+    psa_aead_encrypt(ps_key_handle, PS_CRYPTO_ALG,
+                     crypto->ref.iv, PS_IV_LEN_BYTES,
                      add, add_len,
                      in, in_len,
                      out, out_size, out_len)
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 6f27f33..73e91aa 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -80,9 +80,13 @@
         A component within the TEE that is atomic from a security/trust point of
         view, i.e. which is viewed as a single entity from a TF-M point of view.
 
-    SST : TF-M related
-    Secure Storage Service
-        Secure storage service provided by TF-M.
+    PS : TF-M related
+    Protected Storage
+        Protected storage service provided by TF-M.
+
+    ITS : TF-M related
+    Internal Trusted Storage
+        Internal Trusted Storage service provided by TF-M.
 
     TFM
     TF-M
diff --git a/docs/user_guides/services/tfm_its_integration_guide.rst b/docs/user_guides/services/tfm_its_integration_guide.rst
index f668913..f6b2dec 100644
--- a/docs/user_guides/services/tfm_its_integration_guide.rst
+++ b/docs/user_guides/services/tfm_its_integration_guide.rst
@@ -115,7 +115,7 @@
 - ``tfm_internal_trusted_storage.c`` - Contains the TF-M internal trusted
   storage API implementations which are the entry points to the ITS service.
   Allocates a filesystem context for ITS and makes appropriate fs calls. Also
-  handles requests from the SST partition with a separate fs context.
+  handles requests from the PS partition with a separate fs context.
 
 - ``its_utils.c`` - Contains common and basic functionalities used across the
   ITS service code.
@@ -170,7 +170,7 @@
 
 - ``flash/its_flash_info_external.c`` - Defines an instance of the
   ``struct its_flash_info_t`` type for the external flash device, used only to
-  handle requests from the SST partition.
+  handle requests from the PS partition.
 
 The CMSIS flash interface **must** be implemented for each target based on its
 flash controller.
diff --git a/docs/user_guides/services/tfm_sst_integration_guide.rst b/docs/user_guides/services/tfm_ps_integration_guide.rst
similarity index 65%
rename from docs/user_guides/services/tfm_sst_integration_guide.rst
rename to docs/user_guides/services/tfm_ps_integration_guide.rst
index 6c860d2..1f47204 100644
--- a/docs/user_guides/services/tfm_sst_integration_guide.rst
+++ b/docs/user_guides/services/tfm_ps_integration_guide.rst
@@ -1,21 +1,21 @@
-########################################
-Secure Storage Service Integration Guide
-########################################
+###########################################
+Protected Storage Service Integration Guide
+###########################################
 
 ************
 Introduction
 ************
-TF-M Secure Storage (SST) service implements PSA Protected Storage APIs.
+TF-M Protected Storage (PS) service implements PSA Protected Storage APIs.
 
 The service is backed by hardware isolation of the flash access domain and, in
 the current version, relies on hardware to isolate the flash area from
 non-secure access. In absence of hardware level isolation, the secrecy and
 integrity of data is still maintained.
 
-The SST service implements an AES-GCM based AEAD encryption policy, as a
+The PS service implements an AES-GCM based AEAD encryption policy, as a
 reference, to protect data integrity and authenticity.
 
-SST reuses the non-hierarchical filesystem provided by the TF-M Internal Trusted
+PS reuses the non-hierarchical filesystem provided by the TF-M Internal Trusted
 Storage service to store encrypted, authenticated objects on the external flash
 device.
 
@@ -29,7 +29,7 @@
 
 - **Integrity** - Resistant to tampering by either the normal users of a product,
   package, or system or others with physical access to it. If the content of the
-  secure storage is changed maliciously, the service is able to detect it.
+  protected storage is changed maliciously, the service is able to detect it.
 
 - **Reliability** - Resistant to power failure scenarios and incomplete write
   cycles.
@@ -42,9 +42,9 @@
   very small silicon footprint, the PPA (power, performance, area) should be
   optimal.
 
-*******************************
-Current SST Service Limitations
-*******************************
+******************************
+Current PS Service Limitations
+******************************
 - **Fragmentation** - The current design does not support fragmentation, as an
   asset is stored in a contiguous space in a block. This means that the maximum
   asset size can only be up-to a block size. Detailed information about the
@@ -91,19 +91,19 @@
 **************
 Code Structure
 **************
-Secure storage service code is located in ``secure_fw/partitions/secure_storage/``
-and is divided as follows:
+Protected storage service code is located in
+``secure_fw/partitions/protected_storage/`` and is divided as follows:
 
     - Core files
     - Cryptographic interfaces
     - Non-volatile (NV) counters interfaces
 
-The PSA PS interfaces for SST service are located in ``interface/include/psa``
+The PSA PS interfaces for PS service are located in ``interface/include/psa``
 
 PSA Protected Storage Interfaces
 ================================
 
-The SST service exposes the following mandatory PSA PS interfaces, version 1.0:
+The PS service exposes the following mandatory PSA PS interfaces, version 1.0:
 
 .. code-block:: c
 
@@ -115,41 +115,41 @@
 
 For the moment, it does not support the extended version of those APIs.
 
-These PSA PS interfaces and SST TF-M types are defined and documented in
+These PSA PS interfaces and PS TF-M types are defined and documented in
 ``interface/include/psa/protected_storage.h``,
 ``interface/include/psa/storage_common.h`` and
-``interface/include/tfm_sst_defs.h``
+``interface/include/tfm_ps_defs.h``
 
 Core Files
 ==========
-- ``tfm_sst_req_mngr.c`` - Contains the SST request manager implementation which
+- ``tfm_ps_req_mngr.c`` - Contains the PS request manager implementation which
   handles all requests which arrive to the service. This layer extracts the
   arguments from the input and output vectors, and it calls the protected
   storage layer with the provided parameters.
 
 - ``tfm_protected_storage.c`` - Contains the TF-M protected storage API
-  implementations which are the entry points to the SST service.
+  implementations which are the entry points to the PS service.
 
-- ``sst_object_system.c`` - Contains the object system implementation to manage
-  all objects in SST area.
+- ``ps_object_system.c`` - Contains the object system implementation to manage
+  all objects in PS area.
 
-- ``sst_object_table.c`` - Contains the object system table implementation which
-  complements the object system to manage all object in the SST area.
+- ``ps_object_table.c`` - Contains the object system table implementation which
+  complements the object system to manage all object in the PS area.
   The object table has an entry for each object stored in the object system
   and keeps track of its version and owner.
 
-- ``sst_encrypted_object.c`` - Contains an implementation to manipulate
-  encrypted objects in the SST object system.
+- ``ps_encrypted_object.c`` - Contains an implementation to manipulate
+  encrypted objects in the PS object system.
 
-- ``sst_utils.c`` - Contains common and basic functionalities used across the
-  SST service code.
+- ``ps_utils.c`` - Contains common and basic functionalities used across the
+  PS service code.
 
 Flash Filesystem and Flash Interfaces
 =====================================
-The SST service reuses the non-hierarchical filesystem and flash interfaces
+The PS service reuses the non-hierarchical filesystem and flash interfaces
 provided by the TF-M Internal Trusted Storage service. It stores encrypted,
 authenticated objects on the external flash device by making service calls to
-the ITS service. When the ITS service receives requests from the SST partition,
+the ITS service. When the ITS service receives requests from the PS partition,
 it handles the request by using a separate filesystem context initialised to use
 the external flash device.
 
@@ -161,81 +161,81 @@
 </docs/user_guides/services/tfm_its_integration_guide>`.
 
 The structure containing info about the external flash device, used by the ITS
-service to handle requests from the SST partition, is defined in
+service to handle requests from the PS partition, is defined in
 ``secure_fw/partitions/internal_trusted_storage/flash/its_flash_info_external.c``,
 which depends on target-specific definitions from
 ``platform/ext/target/<TARGET_NAME>/partition/flash_layout.h``. Please see the
-`Secure Storage Service Definitions` section for details.
+`Protected Storage Service Definitions` section for details.
 
 Cryptographic Interface
 =======================
-- ``crypto/sst_crypto_interface.h`` - Abstracts the cryptographic operations for
-  the secure storage service.
+- ``crypto/ps_crypto_interface.h`` - Abstracts the cryptographic operations for
+  the protected storage service.
 
-- ``crypto/sst_crypto_interface.c`` - Implements the SST service cryptographic
+- ``crypto/ps_crypto_interface.c`` - Implements the PS service cryptographic
   operations with calls to the TF-M Crypto service.
 
 Non-volatile (NV) Counters Interface
 ====================================
-The current SST service provides rollback protection based on NV
+The current PS service provides rollback protection based on NV
 counters.
-SST defines and implements the following NV counters functionalities:
+PS defines and implements the following NV counters functionalities:
 
-- ``nv_counters/sst_nv_counters.h`` - Abstracts SST non-volatile
+- ``nv_counters/ps_nv_counters.h`` - Abstracts PS non-volatile
   counters operations. This API detaches the use of NV counters from the TF-M NV
   counters implementation, provided by the platform, and provides a mechanism to
-  compile in a different API implementation for test purposes. A SST test suite
-  **may** provide its own custom implementation to be able to test different SST
+  compile in a different API implementation for test purposes. A PS test suite
+  **may** provide its own custom implementation to be able to test different PS
   service use cases.
 
-- ``nv_counters/sst_nv_counters.c`` - Implements the SST NV counters interfaces
+- ``nv_counters/ps_nv_counters.c`` - Implements the PS NV counters interfaces
   based on TF-M NV counters implementation provided by the platform.
 
-*****************************
-SST Service Integration Guide
-*****************************
+****************************
+PS Service Integration Guide
+****************************
 This section describes mandatory (i.e. **must** implement) or optional
 (i.e. **may** implement) interfaces which the system integrator have to take
-in to account in order to integrate the secure storage service in a new
+in to account in order to integrate the protected storage service in a new
 platform.
 
 Maximum Asset Size
 ==================
 An asset is stored in a contiguous space in a block/sector. The maximum
 size of an asset can be up-to the size of the data block/sector minus the object
-header size (``SST_OBJECT_HEADER_SIZE``) which is defined in
-``sst_object_defs.h``. The ``SST_OBJECT_HEADER_SIZE`` changes based on the
-``SST_ENCRYPTION`` flag status.
+header size (``PS_OBJECT_HEADER_SIZE``) which is defined in
+``ps_object_defs.h``. The ``PS_OBJECT_HEADER_SIZE`` changes based on the
+``PS_ENCRYPTION`` flag status.
 
-Secure Storage Service Definitions
-==================================
-The SST service requires the following platform definitions:
+Protected Storage Service Definitions
+=====================================
+The PS service requires the following platform definitions:
 
-- ``SST_FLASH_AREA_ADDR`` - Defines the flash address where the secure storage
+- ``PS_FLASH_AREA_ADDR`` - Defines the flash address where the protected storage
   area starts.
-- ``SST_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area
-  for secure storage in bytes.
-- ``SST_SECTOR_SIZE`` - Defines the size of the flash sectors (the smallest
+- ``PS_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area
+  for protected storage in bytes.
+- ``PS_SECTOR_SIZE`` - Defines the size of the flash sectors (the smallest
   erasable unit) in bytes.
-- ``SST_SECTORS_PER_BLOCK`` - Defines the number of contiguous SST_SECTOR_SIZE
+- ``PS_SECTORS_PER_BLOCK`` - Defines the number of contiguous PS_SECTOR_SIZE
   to form a logical block in the filesystem.
-- ``SST_FLASH_DEV_NAME`` - Specifies the flash device used by SST to store the
+- ``PS_FLASH_DEV_NAME`` - Specifies the flash device used by PS to store the
   data.
-- ``SST_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
-  bytes. Valid values are powers of two between 1 and ``SST_SECTOR_SIZE``
+- ``PS_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
+  bytes. Valid values are powers of two between 1 and ``PS_SECTOR_SIZE``
   inclusive.
-- ``SST_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
-  SST area. This size is used to define the temporary buffers used by SST to
+- ``PS_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
+  PS area. This size is used to define the temporary buffers used by PS to
   read/write the asset content from/to flash. The memory used by the temporary
-  buffers is allocated statically as SST does not use dynamic memory allocation.
-- ``SST_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
-  SST area. This number is used to dimension statically the object table size in
+  buffers is allocated statically as PS does not use dynamic memory allocation.
+- ``PS_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
+  PS area. This number is used to dimension statically the object table size in
   RAM (fast access) and flash (persistent storage). The memory used by the
-  object table is allocated statically as SST does not use dynamic memory
+  object table is allocated statically as PS does not use dynamic memory
   allocation.
 
-The sectors reserved to be used as secure storage **must** be contiguous sectors
-starting at ``SST_FLASH_AREA_ADDR``.
+The sectors reserved to be used as protected storage **must** be contiguous
+sectors starting at ``PS_FLASH_AREA_ADDR``.
 
 The design requires either 2 blocks, or any number of blocks greater than or
 equal to 4. Total number of blocks can not be 0, 1 or 3. This is a design choice
@@ -245,7 +245,7 @@
 information explained above. The defines must be named as they are specified
 above.
 
-More information about the ``flash_layout.h`` content, not SST related, is
+More information about the ``flash_layout.h`` content, not PS related, is
 available in :doc:`platform readme </platform/ext/readme>` along with other
 platform information.
 
@@ -256,7 +256,7 @@
 ``platform/include/tfm_plat_nv_counters.h``
 
 The system integrators **may** implement this interface based on the target
-capabilities and set the ``SST_ROLLBACK_PROTECTION`` flag to compile in
+capabilities and set the ``PS_ROLLBACK_PROTECTION`` flag to compile in
 the rollback protection code.
 
 Secret Platform Unique Key
@@ -279,7 +279,7 @@
 :doc:`NS client identification documentation </docs/user_guides/tfm_ns_client_identification>`
 provides further details on how client identification works.
 
-SST service uses that TF-M core API to retrieve the client ID and associate it
+PS service uses that TF-M core API to retrieve the client ID and associate it
 as the owner of an asset. Only the owner can read, write or delete that asset
 based on the creation flags.
 
@@ -291,46 +291,46 @@
 The reference encryption policy is built on AES-GCM, and it **may** be replaced
 by a vendor specific implementation.
 
-The SST service abstracts all the cryptographic requirements and specifies the
+The PS service abstracts all the cryptographic requirements and specifies the
 required cryptographic interface in
-``secure_fw/partitions/secure_storage/crypto/sst_crypto_interface.h``
+``secure_fw/partitions/protected_storage/crypto/ps_crypto_interface.h``
 
-The SST service cryptographic operations are implemented in
-``secure_fw/partitions/secure_storage/crypto/sst_crypto_interface.c``, using calls
-to the TF-M Crypto service.
+The PS service cryptographic operations are implemented in
+``secure_fw/partitions/protected_storage/crypto/ps_crypto_interface.c``, using
+calls to the TF-M Crypto service.
 
-SST Service Features Flags
-==========================
-SST service defines a set of flags that can be used to compile in/out certain
-SST service features. The ``CommonConfig.cmake`` file sets the default values
+PS Service Features Flags
+=========================
+PS service defines a set of flags that can be used to compile in/out certain
+PS service features. The ``CommonConfig.cmake`` file sets the default values
 of those flags. However, those flags values can be overwritten by setting them
 in ``platform/ext/<TARGET_NAME>.cmake`` based on the target capabilities or
-needs. The list of SST services flags are:
+needs. The list of PS services flags are:
 
-- ``SST_ENCRYPTION``- this flag allows to enable/disable encryption
-  option to encrypt the secure storage data.
-- ``SST_CREATE_FLASH_LAYOUT``- this flag indicates that it is required
-  to create a SST flash layout. If this flag is set, SST service will
-  generate an empty and valid SST flash layout to store assets. It will
-  erase all data located in the assigned SST memory area before generating
-  the SST layout.  This flag is required to be set if the SST memory area
-  is located in a non-persistent memory.  This flag can be set if the SST
-  memory area is located in a persistent memory without a valid SST flash
+- ``PS_ENCRYPTION``- this flag allows to enable/disable encryption
+  option to encrypt the protected storage data.
+- ``PS_CREATE_FLASH_LAYOUT``- this flag indicates that it is required
+  to create a PS flash layout. If this flag is set, PS service will
+  generate an empty and valid PS flash layout to store assets. It will
+  erase all data located in the assigned PS memory area before generating
+  the PS layout.  This flag is required to be set if the PS memory area
+  is located in a non-persistent memory.  This flag can be set if the PS
+  memory area is located in a persistent memory without a valid PS flash
   layout in it. That is the case when it is the first time in the device
-  life that the SST service is executed.
-- ``SST_VALIDATE_METADATA_FROM_FLASH``- this flag allows to
+  life that the PS service is executed.
+- ``PS_VALIDATE_METADATA_FROM_FLASH``- this flag allows to
   enable/disable the validation mechanism to check the metadata store in flash
   every time the flash data is read from flash. This validation is required
   if the flash is not hardware protected against malicious writes. In case
   the flash is protected against malicious writes (i.e embedded flash, etc),
   this validation can be disabled in order to reduce the validation overhead.
-- ``SST_ROLLBACK_PROTECTION``- this flag allows to enable/disable
-  rollback protection in secure storage service. This flag takes effect only
-  if the target has non-volatile counters and ``SST_ENCRYPTION`` flag is on.
-- ``SST_RAM_FS``- this flag allows to enable/disable the use of RAM
-  instead of the flash to store the FS in secure storage service. This flag
+- ``PS_ROLLBACK_PROTECTION``- this flag allows to enable/disable
+  rollback protection in protected storage service. This flag takes effect only
+  if the target has non-volatile counters and ``PS_ENCRYPTION`` flag is on.
+- ``PS_RAM_FS``- this flag allows to enable/disable the use of RAM
+  instead of the flash to store the FS in protected storage service. This flag
   is set by default in the regression tests, if it is not defined by the
-  platform.  The SST regression tests reduce the life of the flash memory
+  platform.  The PS regression tests reduce the life of the flash memory
   as they write/erase multiple times in the memory.
 
   .. Note::
@@ -340,16 +340,16 @@
     specific (QSPI, eFlash, etc.) and it is described in corresponding
     flash_layout.h
 
-- ``SST_TEST_NV_COUNTERS``- this flag enables the virtual
-  implementation of the SST NV counters interface in
-  ``test/suites/sst/secure/nv_counters``, which emulates NV counters in
+- ``PS_TEST_NV_COUNTERS``- this flag enables the virtual
+  implementation of the PS NV counters interface in
+  ``test/suites/ps/secure/nv_counters``, which emulates NV counters in
   RAM, and disables the hardware implementation of NV counters provided by
   the secure service. This flag is enabled by default when building the
   regression tests and disabled by default otherwise.  This flag can be
   overridden to ``OFF`` when building the regression tests. In this case,
-  the SST rollback protection test suite will not be built, as it relies
+  the PS rollback protection test suite will not be built, as it relies
   on extra functionality provided by the virtual NV counters to simulate
-  different rollback scenarios. The remainder of the SST test suites will
+  different rollback scenarios. The remainder of the PS test suites will
   run using the hardware NV counters. Please note that running the tests in
   this configuration will quickly increase the hardware NV counter values,
   which cannot be decreased again.
diff --git a/docs/user_guides/services/tfm_secure_partition_addition.rst b/docs/user_guides/services/tfm_secure_partition_addition.rst
index 174ae4e..774220a 100644
--- a/docs/user_guides/services/tfm_secure_partition_addition.rst
+++ b/docs/user_guides/services/tfm_secure_partition_addition.rst
@@ -152,7 +152,7 @@
     **Partition name**              **Partition ID**
    =============================== =================
    Reserved                        0-255
-   TFM_SP_STORAGE                  256
+   TFM_SP_PS                       256
    TFM_SP_ITS                      257
    TFM_SP_AUDIT_LOG                258
    TFM_SP_CRYPTO                   259
@@ -164,7 +164,7 @@
    TFM_SP_IPC_SERVICE_TEST         265
    TFM_SP_IPC_CLIENT_TEST          266
    TFM_IRQ_TEST_1                  267
-   TFM_SP_SST_TEST                 268
+   TFM_SP_PS_TEST                  268
    =============================== =================
 
 About where to add the definition, please refer to the chapter `Add
@@ -188,7 +188,7 @@
    audit_logging               0x00000                0x000-0x01F
    initial_attestation         0x00000                0x020-0x03F
    platform                    0x00000                0x040-0x05F
-   secure_storage              0x00000                0x060-0x07F
+   protected_storage           0x00000                0x060-0x07F
    crypto                      0x00000                0x080-0x09F
    internal_trusted_storage    0x00000                0x0A0-0x0BF
    test_secure_service         0x0000F                0x000-0x01F
@@ -197,7 +197,7 @@
    tfm_ipc_client              0x0000F                0x060-0x07F
    tfm_ipc_service             0x0000F                0x080-0x09F
    tfm_irq_test_service_1      0x0000F                0x0A0-0x0BF
-   tfm_sst_test_service        0x0000F                0x0C0-0x0DF
+   tfm_ps_test_service         0x0000F                0x0C0-0x0DF
    =========================== ====================== ========================
 
 mmio_regions
@@ -349,4 +349,4 @@
 
 --------------
 
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
\ No newline at end of file
+*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_build_instruction.rst b/docs/user_guides/tfm_build_instruction.rst
index 8ed8c2d..de910ad 100644
--- a/docs/user_guides/tfm_build_instruction.rst
+++ b/docs/user_guides/tfm_build_instruction.rst
@@ -91,7 +91,7 @@
 file. The build system assumes that the PSA API compliance test suite is checked
 out at the same level of the TF-M root folder and the default name for the build
 folder has been used when compiling the PSA API compliance tests. Each set of
-tests for the Internal Trusted Storage, Secure Storage, Crypto and Attestation
+tests for the Internal Trusted Storage, Protected Storage, Crypto and Attestation
 services needs to be enabled at the build configuration step by defining::
 
     -DPSA_API_TEST_INTERNAL_TRUSTED_STORAGE=ON
diff --git a/docs/user_guides/tfm_integration_guide.rst b/docs/user_guides/tfm_integration_guide.rst
index d320a0e..09e43a0 100644
--- a/docs/user_guides/tfm_integration_guide.rst
+++ b/docs/user_guides/tfm_integration_guide.rst
@@ -67,7 +67,7 @@
 
 .. Note::
 
-    Currently SST and BL2 bootloader use different flash interface
+    Currently ITS, PS and BL2 bootloader use different flash interface
 
 Target configuration files
 ==========================
@@ -104,13 +104,13 @@
 ``<build_dir>/install/export/tfm`` path. The NS side is only allowed to call
 TF-M secure functions (veneers) from the NS Thread mode. For this reason, the
 API is a collection of functions in the ``<build_dir>/install/export/tfm/inc``
-directory. For example, the interface for the Secure STorage (SST) service
-is described in the file ``psa_sst_api.h`` as a collection of functions that
+directory. For example, the interface for the Protected Storage (PS) service
+is described in the file ``psa_ps_api.h`` as a collection of functions that
 call service veneer functions. This API is a wrapper for the secure veneers,
 and returns the return value from the service to the caller.
 
-The secure storage service uses a numerical ID, to identify the clients that use
-the service. For details see
+The protected storage service uses a numerical ID, to identify the clients that
+use the service. For details see
 :doc:`ns client identification documentation <tfm_ns_client_identification>`.
 
 Interface with non-secure world regression tests
@@ -123,7 +123,7 @@
 tests are precompiled and delivered as a static library which is available in
 ``<build_dir>/install/export/tfm/test/lib``, so that the non-secure application
 needs to link against the library to be able to invoke the
-``tfm_non_secure_client_run_tests()`` function. The SST non-secure side
+``tfm_non_secure_client_run_tests()`` function. The PS non-secure side
 regression tests rely on some OS functionality e.g. threads, mutexes etc. These
 functions comply with CMSIS RTOS2 standard and have been exported as thin
 wrappers defined in ``os_wrapper.h`` contained in
@@ -148,4 +148,4 @@
 
 --------------
 
-*Copyright (c) 2017-2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2017-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_ns_client_identification.rst b/docs/user_guides/tfm_ns_client_identification.rst
index 9faccfb..44fd343 100644
--- a/docs/user_guides/tfm_ns_client_identification.rst
+++ b/docs/user_guides/tfm_ns_client_identification.rst
@@ -1,7 +1,7 @@
 ###########################
 Non-Secure Identity Manager
 ###########################
-The ID of the current application/thread is known by TF-M, and the SST service
+The ID of the current application/thread is known by TF-M, and the PS service
 queries the ID of the currently running client via a dedicated API.
 
 The identity of secure clients can be tracked by TF-M core, because it also
@@ -40,4 +40,4 @@
 
 --------------
 
-*Copyright (c) 2018-2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2018-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_secure_boot.rst b/docs/user_guides/tfm_secure_boot.rst
index a62d836..917d018 100644
--- a/docs/user_guides/tfm_secure_boot.rst
+++ b/docs/user_guides/tfm_secure_boot.rst
@@ -568,7 +568,7 @@
     [Sec Thread] Secure image initializing!
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
     ...
 
 To update the secure and non-secure images separately (multiple image boot),
@@ -617,7 +617,7 @@
     [Sec Thread] Jumping to non-secure code...
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
     ...
 
 Swapping firmware upgrade
@@ -646,7 +646,7 @@
     [Sec Thread] Secure image initializing!
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
     ...
 
 Non-swapping firmware upgrade
@@ -723,7 +723,7 @@
     [Sec Thread] Secure image initializing!
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
     ...
 
 Executing firmware upgrade on CoreLink SSE-200 Subsystem for MPS3 (AN524)
diff --git a/docs/user_guides/tfm_user_guide.rst b/docs/user_guides/tfm_user_guide.rst
index 11061a2..eaf33f6 100644
--- a/docs/user_guides/tfm_user_guide.rst
+++ b/docs/user_guides/tfm_user_guide.rst
@@ -131,30 +131,30 @@
     [INF] Jumping to the first image slot
     [Sec Thread] Secure image initializing!
 
-    #### Execute test suites for the secure storage service ####
-    Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
+    #### Execute test suites for the protected storage service ####
+    Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
 
-    > Executing 'TFM_SST_TEST_2001'
+    > Executing 'TFM_PS_TEST_2001'
       Description: 'Create interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2002'
+    > Executing 'TFM_PS_TEST_2002'
       Description: 'Get handle interface (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2003'
+    > Executing 'TFM_PS_TEST_2003'
       Description: 'Get handle with null handle pointer (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2004'
+    > Executing 'TFM_PS_TEST_2004'
       Description: 'Write interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2005'
+    > Executing 'TFM_PS_TEST_2005'
       Description: 'Read interface'
     ....
 
 .. Note::
 
-    SST reliability tests take a few minutes to run on the MPS2.
+    PS reliability tests take a few minutes to run on the MPS2.
 
 Example application without BL2 bootloader
 ------------------------------------------
@@ -187,24 +187,24 @@
 
     [Sec Thread] Secure image initializing!
 
-    #### Execute test suites for the secure storage service ####
-    Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
+    #### Execute test suites for the protected storage service ####
+    Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
 
-    > Executing 'TFM_SST_TEST_2001'
+    > Executing 'TFM_PS_TEST_2001'
       Description: 'Create interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2002'
+    > Executing 'TFM_PS_TEST_2002'
       Description: 'Get handle interface (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2003'
+    > Executing 'TFM_PS_TEST_2003'
       Description: 'Get handle with null handle pointer (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2004'
+    > Executing 'TFM_PS_TEST_2004'
       Description: 'Write interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2005'
+    > Executing 'TFM_PS_TEST_2005'
       Description: 'Read interface'
     ....
 
@@ -286,23 +286,23 @@
     [INF] Jumping to the first image slot
     [Sec Thread] Secure image initializing!
 
-    #### Execute test suites for the secure storage service ####
-    Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
-    > Executing 'TFM_SST_TEST_2001'
+    #### Execute test suites for the protected storage service ####
+    Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
+    > Executing 'TFM_PS_TEST_2001'
       Description: 'Create interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2002'
+    > Executing 'TFM_PS_TEST_2002'
       Description: 'Get handle interface (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2003'
+    > Executing 'TFM_PS_TEST_2003'
       Description: 'Get handle with null handle pointer (DEPRECATED)'
     This test is DEPRECATED and the test execution was SKIPPED
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2004'
+    > Executing 'TFM_PS_TEST_2004'
       Description: 'Get attributes interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2005'
+    > Executing 'TFM_PS_TEST_2005'
       Description: 'Get attributes with null attributes struct pointer'
     ....
 
@@ -396,17 +396,17 @@
     [Sec Thread] Secure image initializing!
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
-    > Executing 'TFM_SST_TEST_2001'
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
+    > Executing 'TFM_PS_TEST_2001'
       Description: 'Set interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2002'
+    > Executing 'TFM_PS_TEST_2002'
       Description: 'Set interface with create flags'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2003'
+    > Executing 'TFM_PS_TEST_2003'
       Description: 'Set interface with NULL data pointer'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2004'
+    > Executing 'TFM_PS_TEST_2004'
       Description: 'Set interface with invalid data length'
       TEST PASSED!
     ....
@@ -449,17 +449,17 @@
     [Sec Thread] Secure image initializing!
 
     #### Execute test suites for the Secure area ####
-    Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
-    > Executing 'TFM_SST_TEST_2001'
+    Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
+    > Executing 'TFM_PS_TEST_2001'
       Description: 'Set interface'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2002'
+    > Executing 'TFM_PS_TEST_2002'
       Description: 'Set interface with create flags'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2003'
+    > Executing 'TFM_PS_TEST_2003'
       Description: 'Set interface with NULL data pointer'
       TEST PASSED!
-    > Executing 'TFM_SST_TEST_2004'
+    > Executing 'TFM_PS_TEST_2004'
       Description: 'Set interface with invalid data length'
       TEST PASSED!
     ....