Zero Trust relies on continuously re-authorizing users, applications, and devices to establish myriad \u201cperimeters of one\u201d in the environment, but the name isn\u2019t quite accurate.\nZero Trust doesn\u2019t literally mean zero trust; it means zero implicit trust. You\u2014whether that means a person, or a software or hardware system\u2014are not to be trusted simply by virtue of where you are on the network; there is no network perimeter within which you are automatically trusted to connect to services. And you are not to be trusted now just because you were trusted when you first gained access to the network; gaining admission once is not the same thing as ongoing trust. And you are not to be trusted to make the new service connection you are trying to make now just because you were trusted to make the previous one.\n\nSo, in a ZT environment, each time someone or something tries to connect to a service, they are once again authenticated, and their right to use that service\u2014in that way, at that time, from wherever they are at the moment\u2014is re-verified. Architecturally, policy decision points use a trust map to evaluate requests before instructing one or more policy enforcement points to block or allow the requested sessions. \u201cAt that time\u201d is a critical aspect of Zero Trust. The trust map is dynamic, and ideally it is updated in real time based on behavioral threat analytics run against actual, ongoing network activities.\nThe other crucial point: Zero Trust is an approach, not a product. ZT can be implemented at the network level (Zero Trust network access, ZTNA), at an application level, and at a data level, and individual products don\u2019t play across all three domains.\nSoftware-defined perimeter: Zero Trust without the feedback loop\nSoftware-defined perimeter (SDP) as a concept actually predates Zero Trust. It implements the whole decision point\/ trust-map\/enforcement-point architecture at the network layer. That is, it is about controlling when packets are allowed to flow. When node A is not allowed to access services on node B, it will not even be able to detect that node B is there on the network; packets sent toward node B will simply be dropped. If node A is allowed to access, say, only encrypted web services via port 443, then it will not be able to get packets sent to any other port. It is \u201calmost\u201d zero trust only because, as defined, SDP does not require the behavioral feedback loop that Zero Trust uses to keep the trust map up-to-date. Vendors are, however,\u00a0 closing this gap, turning their solutions into fully-fledged ZTNA systems.\nSDP is a huge step toward full Zero Trust and one that can be used to control access from known devices, whether on a company network or remote, to company services, whether in a data center or in a cloud.\nSDP a good place to start\nUsing SDP to replace VPNs for remote access to company resources makes a great first use case for ZT in many networks because\n\nIt is a well-defined problem to solve, comprising limited and known use cases\nCurrent VPN solutions are often cranky for both admins and users, who tell us they are\n\nprone to breaking, so user sessions drop\neasy to misconfigure\ncomplex to manage when many groups with divergent access needs share them or there are multiple security siloes in the infrastructure to manage access to,\nfrequently an impediment to quick, reliable access to protected systems\n\n\nManaging groups and individuals with widely divergent access needs is central to what an SDP is designed to do\nVPN-like levels of access control are simple to replicate\nSDP makes it easy to get far more granular about access rights quickly\n\nPlan ZTNA thoroughly first\nNemertes most recent research on cybersecurity, the Secure Cloud Access and Policy Enforcement Research Study 2021-22, finds that the most successful security organizations that embrace Zero Trust approach it differently from most. The others dive in fast, undertaking not just defining their Zero Trust architecture in the first phase of the effort but also beginning to rearchitect networks and security, and to buy tools, and to put together their implementation team. By contrast, the more successful organizations limit the first phase of the effort to defining the ZT architecture. From there they pursue rearchitecting networks and security, and only after that do they pursue implementation.\nThe take-away is, get Zero Trust into your thinking for all future cybersecurity, now. Begin your Zero Trust journey by defining a Zero Trust architecture for your organization, then re-evaluating network and security architectures. When you get to the point of deciding where to begin implementing, take a hard look at SDP. Not only is it a logical jumping off point to improving your security posture, it could have significant payoffs in terms of improved user experience and reduced cybersecurity-staff workload.