diff --git a/docs/trusted-board-boot.rst b/docs/trusted-board-boot.rst
index 6a28da0..5ab32fe 100644
--- a/docs/trusted-board-boot.rst
+++ b/docs/trusted-board-boot.rst
@@ -12,16 +12,16 @@
 normal world bootloader. It does this by establishing a Chain of Trust using
 Public-Key-Cryptography Standards (PKCS).
 
-This document describes the design of ARM Trusted Firmware TBB, which is an
-implementation of the Trusted Board Boot Requirements (TBBR) specification,
-ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
+This document describes the design of Trusted Firmware-A (TF-A) TBB, which is
+an implementation of the Trusted Board Boot Requirements (TBBR) specification,
+Arm DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
 design document, which implements a specific aspect of the TBBR.
 
 Chain of Trust
 --------------
 
 A Chain of Trust (CoT) starts with a set of implicitly trusted components. On
-the ARM development platforms, these components are:
+the Arm development platforms, these components are:
 
 -  A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
    trusted root-key storage registers.
@@ -39,7 +39,7 @@
 validity of a certificate's issuer but by the content of the certificate
 extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption
 signature scheme is used with a RSA key length of 2048 bits. Future version of
-Trusted Firmware will support additional cryptographic algorithms.
+TF-A will support additional cryptographic algorithms.
 
 The certificates are categorised as "Key" and "Content" certificates. Key
 certificates are used to verify public keys which have been used to sign content
@@ -148,7 +148,7 @@
    registers. If they match, the BL2 hash is read from the certificate.
 
    Note: the matching operation is platform specific and is currently
-   unimplemented on the ARM development platforms.
+   unimplemented on the Arm development platforms.
 
 -  BL1 loads the BL2 image. Its hash is calculated and compared with the hash
    read from the certificate. Control is transferred to the BL2 image if all
@@ -196,7 +196,7 @@
 On the host machine, a tool generates the certificates, which are included in
 the FIP along with the boot loader images. These certificates are loaded in
 Trusted SRAM using the IO storage framework. They are then verified by an
-Authentication module included in the Trusted Firmware.
+Authentication module included in TF-A.
 
 The mechanism used for generating the FIP and the Authentication module are
 described in the following sections.
@@ -204,9 +204,9 @@
 Authentication Framework
 ------------------------
 
-The authentication framework included in the Trusted Firmware provides support
-to implement the desired trusted boot sequence. ARM platforms use this framework
-to implement the boot requirements specified in the TBBR-client document.
+The authentication framework included in TF-A provides support to implement
+the desired trusted boot sequence. Arm platforms use this framework to
+implement the boot requirements specified in the TBBR-client document.
 
 More information about the authentication framework can be found in the
 `Auth Framework`_ document.
@@ -215,8 +215,8 @@
 ---------------------------
 
 The ``cert_create`` tool is built and runs on the host machine as part of the
-Trusted Firmware build process when ``GENERATE_COT=1``. It takes the boot loader
-images and keys as inputs (keys must be in PEM format) and generates the
+TF-A build process when ``GENERATE_COT=1``. It takes the boot loader images
+and keys as inputs (keys must be in PEM format) and generates the
 certificates (in DER format) required to establish the CoT. New keys can be
 generated by the tool in case they are not provided. The certificates are then
 passed as inputs to the ``fiptool`` utility for creating the FIP.
@@ -230,7 +230,7 @@
 
 --------------
 
-*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _Firmware Update: firmware-update.rst
 .. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt