Questions to Ask When a Supplier Claims Their Product Is Zero Trust

TL;DR — "Zero trust" is not a product badge; it is a design approach where every request is checked based on identity, device, context, and policy instead of trusting a network location. The most useful question is: "Show me the exact access flow for a user reaching a sensitive function, including identity check, device check, policy decision, logging, and what happens if one control fails." Reading time: ~7 min

What it is and where it sits

When a supplier says their product is "zero trust," ask them to describe what is being trusted less than before and what now performs the checks.

In plain terms, zero trust means: being on the company network, VPN (private network tunnel), office Wi‑Fi, or a known IP address is not enough to get access. Access should be decided per request or per session using signals such as:

• who the user is, via an identity provider or IdP (login system like Microsoft Entra ID, Okta, Google Workspace)
• whether the device is managed or healthy, via MDM/EDR (device management / endpoint security tools)
• what app or data is being requested
• where the request comes from and when
• what policy allows or blocks it

Architecturally, zero trust usually sits between the user and the app, or between one service and another service. It often replaces older patterns such as:

• "If you are on the VPN, you can reach the internal app"
• "If traffic comes from the office IP, allow it"
• "All internal services can talk to each other"

A typical user-facing flow looks like this:

[User Browser] ---- 1. GET app.example.com ----> [Access Proxy]
[User Browser] <--- 2. redirect to login ---- [Access Proxy]
[User Browser] ---- 3. sign-in ----> [IdP]
[IdP] ---- 4. identity claims ----> [Access Proxy]
[Device/EDR] ---- 5. device posture ----> [Access Proxy]
[Access Proxy] ---- 6. allow request ----> [App]
[Access Proxy] ---- 7. logs/decision ----> [Audit/Siem]

In that diagram:

• The access proxy (gateway that checks requests before forwarding them) is the policy enforcement point.
• The IdP proves who the user is.
• The device tool may report whether the laptop is encrypted, managed, or running security software.
• The app may never be directly exposed to the public internet; only the proxy is.

That is why one of your first buyer questions should be: Where exactly is the policy enforced? If the answer is fuzzy, the zero trust claim probably is too.

How it actually works

The easiest way to test a supplier's understanding is to ask for one complete access story.

End-to-end example: finance manager opens an admin page

Imagine your finance manager wants to open /admin/invoices in a supplier's SaaS product.

Step by step, a real zero trust-style flow should look something like this:

1. The browser requests the page. The user goes to https://app.supplier.com/admin/invoices.

2. The access layer checks for a valid session. If there is no valid session token (signed proof of prior login), the user is redirected to the supplier's IdP or your company's IdP.

3. The user signs in with MFA. MFA (multi-factor authentication) means password plus another factor such as an authenticator app or security key.

4. The access layer receives identity claims. Claims are facts about the user, such as email, department, group membership, and authentication strength.

5. The access layer checks device posture if required. Example policy: only managed laptops can open admin pages; personal devices can only view read-only reports.

6. The policy engine evaluates the request. A concrete policy might be:

   • user must be in finance-admins
   • MFA must have been completed in the last 12 hours
   • device must be managed
   • request must come from a supported country
   • access to /admin/* is read-write; /reports/* is read-only

7. The request is forwarded to the app with identity context. The app receives headers or a token saying who the user is and what groups they belong to.

8. The app still performs authorization. This is important. The gateway should not be the only control. The app should still check: "Is this user allowed to approve invoices?"

9. The decision is logged. Good logs include user, device state, policy matched, resource requested, decision, and reason.

10. If risk changes, access can be challenged again. Example: if the session suddenly appears from another country, the user may be forced to re-authenticate.

That leads directly to the questions you should ask a supplier:

The questions that separate substance from marketing

• What resource is protected by your zero trust controls? Web app, API, admin console, database, SSH, support tooling?
• Where is enforcement? At the CDN, reverse proxy, app, API gateway, service mesh (service-to-service traffic layer), or endpoint agent?
• What identity source do you support? SAML, OIDC (common single sign-on standards), SCIM (user provisioning standard)?
• Can you require MFA for all admin actions, not just login?
• Do you check device posture? If yes, from which tools and what exact signals?
• Can policies differ by route, role, action, API endpoint, or data sensitivity?
• What is still reachable if the access layer fails open or is bypassed?
• Do private services stay private, or are they still internet-exposed behind a login page?
• What logs are produced for allow and deny decisions, and where can we export them?
• How do service accounts and API keys fit into your model? Many products claim zero trust for users but still rely on long-lived shared secrets for APIs.
• How is least privilege enforced? Least privilege means each user or system gets only the minimum access needed.
• Show us the offboarding flow. If an employee leaves, how quickly does access disappear everywhere?
• Show us a break-glass process. Break-glass means emergency access when normal identity systems are down.

If they can answer these with diagrams, screenshots, and sample policies, that is promising. If they answer with slogans like "we verify everything" but cannot show where and how, be cautious.

When to use it (and when not to)

Use zero trust questions when you are buying a product that will handle sensitive data, admin actions, internal tools, or machine-to-machine access.

You probably do not need a deep zero trust architecture review if the product:

• has no sensitive data
• has no privileged workflows
• is not connected to your core systems
• is used by only a few low-risk users
• can be replaced easily if compromised

In those cases, basic security hygiene may matter more than advanced architecture language.

Trade-offs

Zero trust can be very good, but it is not free.

Two honest cautions:

1. Latency can increase. Every check adds a little time. Usually this is acceptable for admin and business apps, but ask for real numbers.
2. Badly designed zero trust can become "login theater." If everything is still broadly reachable after one login, or if long-lived API keys bypass the model, the architecture may not deliver the promised risk reduction.

In practice

Below are examples you can use in supplier conversations or internal reviews. They are not tied to one vendor.

Example 1: A concrete access policy to ask for

Ask the supplier to show something this specific, whether in their dashboard or as exported policy.

{
  "name": "finance-admin-access",
  "resource": "https://app.example.com/admin/*",
  "allow_if": {
    "all": [
      {"user_in_group": "finance-admins"},
      {"mfa_performed_within_hours": 12},
      {"device_managed": true},
      {"country_in": ["GB", "IE", "NL"]}
    ]
  },
  "deny_reason": "Admin access requires finance-admins, recent MFA, and a managed device.",
  "log": true
}

What it does: this expresses the kind of rule a real zero trust product should be able to enforce for a sensitive route. Gotcha: if a supplier can only define one broad rule for the whole app and not for /admin/*, their controls may be too coarse.

Example 2: Reverse proxy passing identity to an app

If a supplier says they enforce access in front of an app, ask whether the app receives verified identity headers or tokens in a controlled way.

location / {
    proxy_pass http://internal_app;
    proxy_set_header X-Authenticated-User $auth_resp_x_user;
    proxy_set_header X-Authenticated-Email $auth_resp_x_email;
    proxy_set_header X-Authenticated-Groups $auth_resp_x_groups;
    proxy_set_header X-Forwarded-Proto https;
}

What it does: this shows a proxy forwarding identity context to an internal app after access checks. Gotcha: the app must trust these headers only from the proxy; if the app is directly reachable from the internet, an attacker may try to spoof them.

Example 3: Questions you can paste into a supplier email

Please describe one complete access flow for a privileged user opening an admin page in your product.
Include:
1. where authentication happens
2. whether SSO via SAML or OIDC is supported
3. whether MFA can be required for admin actions
4. whether device posture is checked and from which tools
5. where policy is enforced
6. whether the application is still directly internet-reachable
7. what logs are generated for allow/deny decisions
8. how service accounts and API access are secured
9. how quickly access is removed after IdP deprovisioning
10. what emergency access process exists if the IdP is unavailable

What it does: this turns a vague sales claim into a concrete request for architecture evidence. Gotcha: if the reply is all prose and no screenshots, diagrams, or sample policy, ask again for specifics.

Further reading

• NIST SP 800-207 Zero Trust Architecture
• Google BeyondCorp papers
• OWASP ASVS Access Control section
• OpenID Connect Core specification
• The "Authentication" and "Authorization" sections of the MDN Web Docs

This article was written by an AI system and published pending human review. Verify anything you intend to act on.