## 2 Background  
The National Security Telecommunications Advisory Committee (NSTAC) report [7] laid out a pragmatic approach to strategies and implement zero trust. The report traces the history of zero trust and USA federal guidelines/policy and moves on to describe zero trust foundational concepts and definitions along with the zero trust five-step implementation process. As the NSTAC report supersedes the earlier publications on zero trust, this paper considers this report as an authoritative source for zero trust. Contrary to the obsolete castle-and-moat model of security, zero trust assumes that the perimeter is breached and does not trust the entities that gained access within the environment by providing the authentication details at the perimeter [1]. Zero trust architecture centres around the protect surface, which is a combination of data, applications, assets and services that an organisation seeks to protect [7]. The implementation process of zero trust applies not only to IT, but also to OT, IoT, smart home devices, etc. [2]. We first describe how the protect surface is different from the attack surface, which is ever evolving [13] and is traditionally used. Figure 1 illustrates an example of the protect surface and the attack surface. In Figure 1 we assume that the databases with Personally Identifiable Information (PII) and cardholder data are of value to the organisation, as any compromise of the data that persists in these databases (confidentiality-, integrity- and availability-wise) may lead to contractual, legal, regulatory and/or statutory impact. The organisation seeks to protect these two servers that are of prime importance from compromises. From a zero-trust perspective these two database servers form one protect surface. On the other hand, the attack surface consists of laptops, the Software-as-a-Service (SaaS) application and the web interface that connects to the database servers, as these ass  
Figure 1: Example of attack surface and protect surface. for a malicious actor to reach the databases in the protect surface, which may result in compromise(s). Figure 2 illustrates the addition of assets (Additional asset and SaaS application 2) to the environment and the impact it has on the attack surface. In Figure 2, assume the organisation adds a new desktop (Additional asset) and a new SaaS application (SaaS application 2) The addition of these two assets increases the attack surface, as they provide more attack paths for a malicious actor to compromise the databases in the protect surface, but does not change the protect surface identified in Figure 1. The protect surface does not change because the database servers that the organisation seeks to secure, the servers for the PII database and cardholder database, remain the same. The paths in orange depict the additional attack paths brought about by the additional assets. This is illustrated in Figure 3.  
In Figure 3 the smart home environment consists of three disparate smart devices from three different vendors, each of which provides a specific functionality distinct from the others. These are smart home devices that connect with their home clouds via a home router to receive updates and upgrades and perhaps share telemetry. Most smart devices also have an interface application (web and/or mobile) that serves as an interface to configure the device. However, smart devices do not communicate amongst themselves. For example, a smart TV does not have any interface to connect with a smart fridge or a smart boiler. A smart fridge does not communicate with a smart boiler to change the heating settings. To compromise the smart devices, a malicious actor needs to (a) compromise the home router (vulnerabilities, open ports, etc.) or (b) conduct a person-in-the-middle attack between the home cloud and the smart device or (c) compromise the home cloud or (d) compromise the interface application.