When a Customer Asks About Zero Trust: What Integrators Need to Say & Do

“Does this access control system support Zero Trust?”
 
 As a security integrator, you’re probably starting to hear this question more frequently from security directors, compliance officers and risk management executives. Your answer will affect whether the customer feels confident moving forward with a given system and how they perceive your depth of expertise. In the physical security space, Zero Trust conversations between integrators and their customers have typically focused on identity authentication:

• How confidently can a system authenticate an individual’s identity? 
• Where and how often must verification occur to create a truly secure environment? 
• What credentials or combination of credentials that can support Zero Trust are most appropriate for the application?

While these are important questions, they represent only one layer of a true Zero Trust architecture. Zero Trust requires continuous verification of identity, device integrity and authorization before granting access to any resource. 

Here are four topics to anchor a thoughtful, technically grounded discussion about how an electronic physical security system should align with Zero Trust principles.

Modern access control solutions continuously exchange data between devices, servers, identity databases, analytic engines and other security and building management platforms. Therefore, they must be evaluated the same way IT considers any other connected infrastructure. In a Zero Trust model, every request between components must be explicitly authenticated, authorized and encrypted — even within the internal network.
 
 A Zero Trust-aligned system should include:

• Mutual TLS (mTLS) or certificate-based authentication between system components.
• Encryption of sensitive data at rest using protected key storage mechanisms (e.g., hardware-backed key storage or secure elements).
• Secure key generation and protected key storage so encryption keys cannot be extracted.
• Authenticated firmware updates that verify the source and integrity of software before installation.
• Secure boot to prevent unauthorized code from loading each time a device powers on.
• Cryptographic device identity so controllers and readers can be uniquely authenticated within the system.

To confirm that the solutions you support meet these requirements, request documentation from their manufacturers. At a minimum, look for:

• Defined encryption standards (TLS versions, AES levels, etc.).
• Third-party certifications or audits (ISO/IEC 27001 and 27701, CSA STAR, EN 60839-11, etc.).
• Published cybersecurity whitepapers detailing encryption methods and key management practices.
• Technical documentation describing the secure boot chain.
• Evidence of regular PEN testing, vulnerability disclosures and patch management processes.

Remember, Zero Trust does not end with hardening. Visibility is what allows an organization to validate trust continuously — not just at deployment.

Modern access control systems rarely operate in isolation. Which begs the next question: how do they connect to other platforms, like video management, visitor management, HR and building automation systems?

Interoperability is important, but the APIs, RESTful APIs and webhooks used to connect disparate systems can create vulnerabilities. Overly permissive API access violates core Zero Trust principles of least privilege and explicit authorization. Integrations should operate as policy-enforced transactions — not persistent trust relationships between systems. Authorization should be governed by dynamic policy that adapts to context, rather than static permissions granted once and left unchanged.

As an integrator, you don’t need to understand every API call, but you should be able to determine whether a connection is narrowly defined and manageable. Practical questions include:

• What is this integration allowed to do?
• Is it limited to specific actions?
• Does it use its own credentials, or are they shared at the system level?
• Can those credentials be revoked or rotated if needed?
• If the connected server changes or is replaced, does the system require reauthorization?

Ask the access control manufacturer for a detailed technical integration guide that answers these questions. For more thorough vetting, your customer’s IT team can review the documentation.

Today’s edge devices run operating systems, process credentials and participate directly in authentication and authorization decisions. They function as distributed enforcement points within the Zero Trust architecture. Zero Trust principles governing software architecture, connectivity and encryption must extend to each controller and reader accordingly.

Additionally, physical compromise must be anticipated. What happens if a reader is removed from the wall or tampered with? Does it wipe all sensitive data? Issue an alert? Or does it continue to operate blindly?
 
 A Zero Trust architecture assumes that any individual device can be compromised. Controllers and edge devices should therefore be logically segmented to prevent lateral movement within the system. Compromise of one component should not grant implicit access to others.

Finally, Zero Trust must extend to identity verification. Too often, organizations prioritize convenience when implementing authentication at managed access points. 

This trade-off appears in the continued reliance on credentials that are easy to issue, share or duplicate. When a system successfully authenticates a credential but cannot reliably verify that the individual presenting is its rightful owner, we must ask ourselves, where is the trust? In these cases, the system is authenticating possession of a credential — not verifying the identity of the subject. 

In a Zero Trust architecture, identity must be strongly bound to a specific individual and validated at the time of access. Within a Zero Trust model, identity controls should include:

• Credentials resistant to cloning or duplication.
• Binding credentials to a specific individual.
• Biometric verification where appropriate.
• Multifactor authentication in higher-risk zones.
• Real-time credential revocation and automatic adjustment of user access based on role or policy changes.

Identity assurance should align with the risk of the protected resource. Higher-risk areas require stronger verification and tighter policy enforcement.

You’re Selling More than Products; You’re Selling Trust

Zero Trust isn’t a bullet on a spec sheet. When customers ask about Zero Trust, they are asking about a discipline that spans software design, integrations, hardware and identity management. Integrators who can articulate how their solutions establish, limit, monitor and revoke trust differentiate themselves from those who just focus on features. In today’s environment, where every system is connected and every connection carries exposure, that understanding is what builds lasting confidence in both the solution and the integrator behind it.