Defining and Enforcing Device Trust: The Culmination of Managed and Compliant Access (Activity 2.4.1) 

Our journey through the Zero Trust Device pillar has brought us to a convergence point. We’ve systematically built the necessary capabilities: establishing a comprehensive device inventory (Activity 2.1.1), forging strong, verifiable identities for devices and non-person entities using PKI and integrating them with our Enterprise IdP (Activity 2.1.2: NPE/PKI, Device under Management), implementing compliance-based network authorization with Comply to Connect (C2C) (Activity 2.2.1: Implement C2C/Compliance Based Network Authorization Part 1), and integrating advanced endpoint protection (NextGenAV/EPP) to inform those compliance checks (Activity 2.3.4: Integrate NextGen AV Tools with C2C). 

Now, Activity 2.4.1: Deny Device by Default Policy establishes and enforces the policy that dictates precisely which devices are authorized to access your resources (applications and data), regardless of whether they are connecting remotely or locally. 

This activity defines a fundamental Zero Trust principle for device access: access to resources (apps/data) is denied by default for all devices. The core of this policy, and the focus of this activity, is setting the standards for and implementing the technical enforcement that a device must be managed and compliant to explicitly be granted access. 

Crucially, the definition of “managed and compliant” in this policy directly leverages the work done in predecessor activities: 

  • “Managed” is linked to the capabilities established in Activity 2.1.2. A device is considered “managed” based on criteria such as possessing a valid enterprise-issued PKI certificate (providing a strong, verifiable identity) and being integrated and tracked as a managed Non-Person Entity (NPE) within the Enterprise IdP. 
  • “Compliant” is linked to meeting the C2C requirements defined and enforced in Activity 2.2.1. These requirements are informed by the status checks performed by integrated endpoint security tools, including the NextGen AV/EPP implemented in Activity 2.3.4 (ensuring the device has up-to-date security software, patches, etc.). 

The policy set in Activity 2.4.1 requires a device to meet both of these criteria – possessing the identity and management status established in 2.1.2 and passing the compliance checks enforced via C2C as defined in 2.2.1 (and informed by 2.3.4) – to be granted access to any data, applications, or services. If a device does not meet both standards, access is denied by default. 

The outcomes of Activity 2.4.1 reflect both the policy definition and the enforcement of this strict default denial for resource access: 

  • Enterprise sets standards for Deny Device by Default policy. (Defining the combined “managed and compliant” criteria based on attributes and status from 2.1.2, 2.2.1, 2.3.4). 
  • Components will block unmanaged devices remotely/locally. (Implementing the technical controls to deny resource access based on not meeting the “managed” criteria, which includes not having the necessary PKI identity from 2.1.2). 
  • Access is enabled strictly for compliant devices remotely/locally following the “Deny Device by Default” policy approach. (Granting access only if the device meets both the managed (with PKI) and compliant (C2C requirements) standards, and blocking if it doesn’t). 

The ultimate end state is a highly controlled environment where resource access is contingent on device trust, enforced by default denial: All device access is authorized, verified, and compliant and all other devices are blocked by default. This means only devices possessing a validated identity, managed within the enterprise framework, and meeting defined security compliance standards can access applications and data. 

Solutions for Achieving Deny Device by Default Policy (Setting Standards and Enforcement) 

Implementing a “Deny Device by Default” policy for resource access requires both defining a clear trust standard based on the outputs of previous activities and deploying technical controls that enforce this standard universally across all resource access pathways. 

  1. Formalizing the “Managed and Compliant” Policy Standard: 
    • This crucial step, driven by enterprise-level governance, involves clearly documenting the technical criteria for a device to be considered “managed and compliant.” This definition directly incorporates: 
      • Criteria for a “managed” device (e.g., enrolled in UEM, possesses enterprise PKI certificate from 1.9.1, managed as NPE in IdP from 2.1.2). 
      • Criteria for a “compliant” device (e.g., meeting C2C requirements from 2.2.1, which include checks informed by EPP/NextGenAV status from 2.3.4). 
    • This policy serves as the central rule for resource access decisions. 
  2. Leveraging Device Assessment Tools to Determine Status: 
    • Endpoint Management (EM) / Unified Endpoint Management (UEM) tools: Provide authoritative data on whether a device is under organizational management, contributing to the “managed” status. 
    • Device Posture Assessment / Endpoint Detection and Response (EDR) tools: Assess the security health and compliance of devices against the defined “compliant” criteria, informed by integrated NextGenAV/EPP status. 
    • Enterprise Identity Provider (IdP) / Identity and Access Management (IdAM) Solutions: Verify the device’s identity (PKI from 2.1.2) and its status as a managed NPE, contributing to the “managed” status. 
  3. Implementing Technical Enforcement Points for Resource Access: 
    • This is the technical implementation aspect – blocking devices that do not meet the “managed and compliant” standard from accessing resources (applications and data).  Or, stated the other way, all devices are blocked unless proven to be managed and compliant. Various enforcement points leverage the policy standard and assessment data: 
      • Zero Trust Network Access (ZTNA) Solutions: Key for remote access enforcement. ZTNA gateways or agents check the device’s managed and compliant status (by integrating with IdP, UEM, device posture tools) before granting access to specific applications. If the status doesn’t meet the policy, access is denied by default. 
      • Application Gateways or Access Proxies: Placed in front of applications (remote or local), these enforce access policies based on device attributes and compliance status. 
      • Network Access Control (NAC) / Comply to Connect (C2C) Solutions: While initially focused on network access (Activity 2.2.1), NAC/C2C can integrate with enforcement points closer to resources or restrict network access for non-compliant devices, effectively blocking resource access. The C2C enforcement from 2.2.1 ensures devices meet compliance standards even before attempting resource access. 
      • Controls within Applications: Some applications may have built-in controls to verify device posture before granting access to sensitive functions or data, utilizing data provided by integrated security tools. 
  4. Integrating Assessment Data with Enforcement Points: 
    • Ensure seamless and real-time integration of the “managed and compliant” status (determined by the assessment tools based on the policy standard) with the various policy enforcement points. This allows for accurate and timely deny/allow decisions for resource access. 

Key Items to Consider: 

  • Unified Policy Definition: The success hinges on a clear, consistent, and technically measurable definition of “managed and compliant” that combines the criteria from Activities 2.1.2, 2.2.1, and 2.3.4. 
  • Reliable and Integrated Assessment Tools: The accuracy and timeliness of the data provided by UEM/EM, device posture/EDR, and IdP tools are critical for determining compliance with the policy standard. Integration between these tools is essential. 
  • Comprehensive Enforcement Coverage: Identify all pathways devices can use to access resources and ensure that appropriate enforcement points are in place to apply the “Deny Device by Default” policy based on the “managed and compliant” status for both remote and local access. 
  • Handling Exceptions: While the goal is strict enforcement, a very limited and strictly controlled risk-based exception process may be needed for specific, low-risk scenarios involving devices that cannot meet the standard. 
  • User Communication and Remediation: Clearly communicate the policy and requirements to users and provide a streamlined process for bringing devices into compliance. 

Relevant Technologies and Tools: 

Successfully implementing Activity 2.4.1 requires a combination of tools for policy definition, device assessment against that policy, and technical enforcement of the default denial for resource access: 

  • Enterprise Policy Management Frameworks: For defining and disseminating the “Deny Device by Default” policy and the combined criteria for “managed and compliant.” 
  • Enterprise Identity Provider (IdP) / Identity and Access Management (IdAM) Solutions: Manage user and NPE identities (including device identities from 2.1.2). Verify the device’s identity (PKI) and its status as a managed NPE, contributing to the “managed” criteria assessment. 
  • Policy Enforcement Points (Various): The tools that technically block access to resources based on the “Deny Device by Default” policy and the assessment of managed/compliant status. This includes: 
  • Zero Trust Network Access (ZTNA) Solutions: Key for remote access enforcement. 
  • Network Access Control (NAC) / Comply to Connect (C2C) Solutions: Enforce at the network layer and contribute to the “compliant” status assessment. 
  • Application Gateways / Access Proxies: Enforce policy before access to specific applications. 
  • Application-Specific Controls: Built-in enforcement within applications. 

The Technical Buyer’s Ultimate Device Access Control Mandate: 

Activity 2.4.1 establishes and enforces a fundamental Zero Trust policy for accessing resources. By setting a clear enterprise-wide standard for what constitutes a trusted device – specifically, being both managed (with a verifiable identity from PKI) and compliant (meeting C2C requirements) – and implementing the technical controls to deny access by default to all others, you significantly reduce risk. For technical buyers, this activity means ensuring that the identity, management, and compliance data gathered in predecessor activities are reliably assessed against the 2.4.1 policy standard and that robust enforcement points are in place to universally apply the “Deny Device by Default” principle for resource access, regardless of device location. This is a critical step in ensuring that only trusted devices, with verified identities and healthy postures, can interact with your valuable applications and data. 

Pillar: Device 

Capability: 2.4 Remote Access 

Activity: 2.4.1 Deny Device by Default Policy 

Phase: Target Level 

Predecessor(s): 2.1.2 NPE/PKI, Device under Management 

Successor(s): None 

Technology Partners