Zero trust for sellers: what it means and what it does not

A buyer says, “We need zero trust.” That sounds like a product requirement, but it is often the beginning of a much bigger architecture and operating conversation.

NIST published SP 800-207, Zero Trust Architecture, on 11 August 2020. It describes zero trust as a shift away from relying on network location or ownership as an automatic basis for trust. The focus moves towards users, assets and resources, with authentication and authorization applied before access to an enterprise resource is established. [Source: NIST, 11 August 2020.]

For a seller, the important lesson is that zero trust is not a single feature, appliance or badge.

Traditional sales language can make security sound perimeter-based: inside is trusted, outside is dangerous.

The zero-trust model challenges that shortcut. The customer needs to know which resource is being protected, who or what is requesting access, and which policy determines whether access should be granted.

That immediately improves discovery.

Instead of asking, “Do you want zero trust?”, ask what the buyer is protecting, which identities need access, what context matters, and where the current decision is too broad or too static.

The question becomes operational rather than fashionable.

Zero-trust conversations often collapse into identity.

Identity is central because access decisions need to know who or what is requesting access. Device state, application identity, resource sensitivity and policy context can also matter.

NIST's SP 800-207A, published 13 September 2023, extends zero-trust access-control ideas into cloud-native and multi-cloud application environments, including service identities and application-level policy. [Source: NIST, 13 September 2023.]

That is a useful warning for sellers: a strong identity feature does not automatically establish that the customer's whole architecture follows zero-trust principles.

The right statement may be that a capability supports a particular part of the access model.

Customers may ask whether a solution is “zero-trust compliant.”

Do not answer that phrase before understanding what they mean.

Are they asking whether the product can participate in a policy decision? Whether it can authenticate users or services? Whether it can enforce resource-level access? Whether the proposed architecture follows a customer standard?

The evidence should match the question.

A product description can support a capability statement. A customer architecture can support a deployment statement. A test can support an observed behaviour. None of those should quietly become proof of an entire enterprise security posture.

A zero-trust design crosses organisational boundaries.

The supplier may provide an enforcement point. The customer may control identities, policies, device posture or network design. A service partner may configure part of the environment. Another system may provide signals used in access decisions.

The sales team should make those responsibilities explicit.

If a customer-owned configuration is required, say so. If a partner has to integrate an identity source, name that dependency. If the product supports a control but the customer has to define the policy, do not describe the outcome as automatic.

This is where commercial credibility comes from.

A zero-trust proof of concept should not become a generic feature tour.

If the customer is worried about access from unmanaged devices, test the relevant access decision. If the issue is service-to-service access, test that boundary. If the concern is policy consistency across environments, define the evidence that would demonstrate it.

The result should state what was tested and what was not.

A successful test in one application should not become a claim that every resource is now protected according to the same model.

You do not need to design the customer's full security architecture.

You do need enough fluency to prevent the phrase “zero trust” from turning into an unsupported marketing claim.

A good seller can explain the principle in plain English, identify the decision the customer is trying to make, bring in the right technical specialist, and keep the final wording inside the evidence.

That is more useful than repeating a slogan.

Zero trust is strongest in a sales conversation when it becomes a set of specific access decisions, responsibilities and proof points rather than a label attached to a product.

Relevant programme: Build evidence-led cybersecurity buying and architecture judgment through the ASTRA Cybersecurity Sales Specialist programme: https://www.astraready.com/programmes/