零信任體系結構(ZTA)的核心是授權核心，涉及網絡控制平面內的設備，該核心確定此信任度并不斷評估每個請求的信任度。假設授權核心是控制平面的一部分，則需要在邏輯上將其與用于應用程序數據通信的網絡部分(數據平面)分開。
基于設計的ZTA和整體方法，授權核心的組件可以組合為一個解決方案，也可以通過基于硬件和/或軟件的單個解決方案完全獨立。這些組件包括：
CommunicationAgent–訪問源應提供足夠的信息來計算置信度。增強的身份屬性，例如用戶和資產狀態，位置，身份驗證方法和信任評分，應包含在每個通信中，以便可以對其進行正確評估。
強制引擎–也稱為強制點。應將其放置在盡可能靠近保護元素(數據)的位置。您可以將其視為數據的保鏢。強制引擎將根據策略授權所請求的通信，并根據策略引擎的要求，持續監視流量以停止通信。例如，執行引擎可以防止發現帶有保護元素的系統。
策略引擎–做出授予資產訪問權限的最終決定，并通知執行引擎。策略規則取決于實現的技術，但通常涉及涉及網絡服務，端點和數據類的訪問者，身份，時間，地點，原因以及訪問方式。
信任/風險引擎–分析請求或行動的風險。信任/風險引擎將已實施的信任算法中的偏差通知策略引擎，對照數據存儲評估通信代理的數據，并使用靜態規則和機器學習來不斷更新代理分數以及代理中的組件分數。實施信任算法可根據企業設置的標準，值和權重以及座席歷史記錄和其他數據的上下文視圖來計算基于分數的置信度，從而提供最佳，最全面的方法來消除威脅。與不考慮歷史數據和其他用戶數據的算法相比，基于分數和基于上下文的信任算法將識別可能停留在用戶角色內的攻擊。例如，分數和基于上下文的信任算法可能會以異常方式或從無法識別的位置訪問正在正常工作時間以外訪問數據的用戶帳戶或角色。僅依賴于一組特定的合格屬性的替代算法可能會評估得更快，但不會具有歷史背景來了解該訪問請求看起來很奇怪-并建議策略引擎在進行下一步操作之前要求進行更好的身份驗證。
數據存儲–如上所述，一種首選方法是實施評分和基于上下文的信任算法。因此，信任/風險和策略引擎必須引用一組存儲的數據，以便對訪問請求或通信行為的更改做出策略決定。包含與用戶，設備，工作負載以及與這些元素的歷史數據和行為分析相關的分類數據相關的各種元素的庫存存儲，將通知決策者做出適當的訪問決策。
可以根據組織的用例，業務流程和風險狀況以多種方式實施ZTA。根據網絡的業務功能，ZTA的授權核心設計不同。例如，在數據資源上具有代理的模型可能足以用于本地客戶端到服務器的通信。但是，在云環境中，在虛擬私有云(VPC)內的每個數據資源上放置一個EnforcementEngine可能并不現實。在這種情況下，可以通過微分段從相同分類下的相等數據資產中創建資源組，并使用網關來處理策略實施。
制定的路線圖或行動計劃，與確定公司目前在實現“零信任”方面的結果的成熟度評估相結合，將有助于指導企業進一步投資于授權核心技術，以填補空白。在評估補充技術時，過去一直對業務有效的特定供應商的投資可能包括同一供應商。由于尚未針對授權核心的關鍵部分(例如，通信代理提供的數據元素，評分等)建立開放標準，因此，認真評估供應商的解決方案以填補在成熟度評估中發現的空白很重要。。
信任算法是一個供應商的解決方案可能支持的關鍵組件，但另一個供應商的解決方案則不支持，或者一個供應商的解決方案的策略組成可能與其他供應商不同。而且，如果在此領域沒有特定的標準，則由于將極高的遷移成本切換到另一種解決方案，企業可能會被鎖定在供應商手中。對任何解決方案的評估都應包括對供應商的解決方案以及供應商的業務的整體看法，該解決方案如何與體系結構中的其他組件鏈接，壽命以及解決方案如何動態擴展以抵消增加的負載
