Zero Trust Architecture
Zero Trust Architecture (ZTA) is a security framework defined by NIST SP 800-207 that requires all users and devices to be authenticated, authorized, and continuously validated before being granted access to applications and data, regardless of whether they are inside or outside the network perimeter. The architecture is built on the principle of "never trust, always verify," replacing implicit trust with explicit verification for every access request. ZTA leverages APIs, identity providers, policy engines, and continuous monitoring to enforce least-privilege access across enterprise resources.
Limited machine-readable signal and partial portal coverage — documentation a human can read, but little a machine or agent can consume without scraping.
API Evangelist profiles Zero Trust Architecture the way a machine reads it — 47 machine-readable artifacts across 5 APIs, pulled from the provider's own public surface and indexed so a developer, an analyst, or an AI agent can evaluate it against every other provider on the network.
Every provider in the network is reduced to the same set of machine-readable artifacts — OpenAPI contracts, event specifications, GraphQL schemas, runnable collections, pricing and rate-limit signals, security posture, OAuth scopes, and the agent surfaces (MCP servers and skills) that let software drive the API on its own. We profile them because the interface is the part of a company you can actually inspect: it is a truer signal of what a provider does than any marketing page. From those artifacts we compute the Kin Score — Zero Trust Architecture scores 39.1/100 (thin), with a separate agent-readiness read of 14/100 (human only). The full breakdown is below, followed by every artifact we hold — each card links through to its machine-readable definition on apis.io.
Kin Score
This is the API Evangelist rating — a single, repeatable read computed from the artifacts on this page. Green fill is points earned; the red track is points possible, so every bar shows earned-versus-possible at a glance.
Kin Score
How this is scored →scored 2026-07-27 · rubric v0.5
How we profile Zero Trust Architecture
Each block below is one kind of artifact we hold for Zero Trust Architecture. For each we say what it is and why it earns a place in the profile, then list every one we've indexed — capped at two rows, scroll within the panel for the rest.
APIs 5
Each API is captured as its own OpenAPI definition — every operation, parameter, and response. This is the single most useful machine-readable description of what an API does, and it's what lets us score, lint, mock, and generate against it without asking the provider for anything.
Individual APIs this provider publishes, each with its own machine-readable definition.
NIST SP 800-207 Zero Trust Architecture
NIST Special Publication 800-207 defines zero trust architecture (ZTA) and provides a roadmap for organizations migrating to ZTA. It describes seven ZTA tenets, three logical co...
NIST SP 800-207A ZTA for Cloud-Native Applications
NIST SP 800-207A extends the original ZTA guidance to cover cloud-native applications in multi-cloud environments. It addresses service mesh architectures, workload identity, mi...
SPIFFE - Secure Production Identity Framework for Everyone
SPIFFE is a CNCF-graduated open standard for workload identity in dynamic environments. It provides a framework for workloads to authenticate to each other using short-lived cry...
SPIRE - SPIFFE Runtime Environment
SPIRE is the reference implementation of SPIFFE, a CNCF-graduated production-ready toolchain for establishing trust between workloads. It issues SVIDs to workloads and exposes t...
Open Policy Agent (OPA)
Open Policy Agent is a CNCF-graduated open source general-purpose policy engine that enables unified, context-aware policy enforcement across APIs, microservices, Kubernetes, an...
Pricing Plans 1
Pricing is part of the interface. Machine-readable plans tell you what a tier costs and includes before you commit — one of the six things the Kin Score reads for commercial clarity.
Published pricing tiers and plan structures.
Rate Limits 1
Rate limits are the difference between a demo that works and a production integration that doesn't fall over. Publishing them is an operational-transparency signal — and a hard requirement for any agent that plans its own throughput.
Documented rate limits and quota policies.
Zero Trust Architecture Rate Limits
RATE LIMITSFinOps 1
Cost, billing, and metering signals let a buyer model the financial operations of an API before it's live. We profile them for the same reason we profile pricing: the money is part of the contract.
Cost, billing, and metering signals for API financial operations.
Features 10
The notable capabilities this provider advertises, captured as structured features so they can be searched and compared instead of read one landing page at a time.
Notable capabilities this provider offers.
Identity Verification
Every access request requires verification of user and device identity regardless of network location.
Least Privilege Access
Access is granted with minimum required permissions on a per-session basis.
Microsegmentation
Networks are divided into small zones to limit lateral movement after breach.
Continuous Monitoring
All network traffic, user behavior, and device health are continuously monitored and analyzed.
Policy Decision Point
Centralized policy engine evaluates access requests against defined policies.
Policy Enforcement Point
Gateway or proxy that enforces access decisions made by the policy engine.
Workload Identity
Cryptographic identity for workloads and services replacing static credentials.
Device Health Attestation
Device posture and compliance are verified before granting access.
Implicit Trust Elimination
No user, device, or network is trusted implicitly, even inside the corporate perimeter.
Multi-Factor Authentication
Strong MFA is required as part of identity verification for all access.
Scroll within the panel for all 10 ·
Semantic Vocabularies 1
JSON-LD contexts give the data shared meaning across APIs. We profile them because semantics are what let a machine reconcile 'customer' here with 'customer' somewhere else.
JSON-LD contexts and semantic vocabularies used across these APIs.
Spectral Rules 1
Governance rulesets we run against this provider's specs — the automated checks behind parts of the score. Profiling them makes the quality bar explicit and re-runnable, not a matter of opinion.
Zero Trust Architecture API Rules
SPECTRALJSON Schema 3
Standalone JSON Schema definitions describe the data models behind the API. We profile them so the shapes are validatable on their own — useful long after a single request is forgotten.
Standalone JSON Schema definitions for this provider's data models.
JSON Structure 2
JSON Structure captures the data shapes in a form built for tooling — a complement to JSON Schema that keeps the model machine-legible.
JSON Structure definitions describing this provider's data shapes.
Zero Trust Architecture Identity Structure
JSON STRUCTUREZero Trust Architecture Policy Structure
JSON STRUCTUREExamples 2
Real request and response payloads are what turn a spec from abstract into obvious — and they're one of the twelve things an agent needs to call an API correctly on the first try.
Example request and response payloads for these APIs.
Security Posture 2
Authentication, domain security, vulnerability disclosure, and trust-center signals — the evidence that a provider takes security seriously enough to document it. We profile it because you can't govern what you can't see.
Authentication, domain security, vulnerability disclosure, and trust-center signals.
Use Cases 8
What developers actually build with this provider — captured so the catalogue answers 'what is this for', not just 'what does this expose'.
What developers build with this provider.
Remote Workforce Security
Providing secure access to enterprise resources for remote employees without VPN.
Cloud Application Access
Controlling access to multi-cloud and SaaS applications with consistent policies.
API Security
Enforcing zero trust principles at API gateways with per-request authentication and authorization.
Kubernetes Workload Identity
Using SPIFFE/SPIRE to assign cryptographic identities to Kubernetes pods.
Supply Chain Security
Verifying identity and integrity of software components and build pipelines.
Government Compliance
Meeting CISA Zero Trust Maturity Model requirements for federal agencies.
Insider Threat Mitigation
Limiting damage from insider threats through continuous monitoring and least privilege.
Multi-Cloud Security
Applying consistent zero trust policies across AWS, Azure, GCP, and private clouds.
Scroll within the panel for all 8 ·
Integrations 10
Pre-built integrations with other platforms tell you where this provider already fits in a stack.
Pre-built integrations with other platforms and tools.
SPIFFE/SPIRE
Workload identity standard providing SVIDs for mutual TLS authentication.
Open Policy Agent
Policy engine serving as the Policy Decision Point in ZTA implementations.
Envoy Proxy
Service mesh proxy enforcing mTLS and authorization policies as PEP.
Istio
Kubernetes service mesh providing ZTA controls through SPIFFE and OPA integration.
HashiCorp Vault
Secrets management platform providing dynamic credentials in ZTA pipelines.
Okta
Identity provider for user and device authentication in ZTA implementations.
Microsoft Entra ID
Cloud identity platform used as Identity Provider in enterprise ZTA deployments.
BeyondCorp Enterprise
Google's ZTA implementation providing context-aware access for enterprise applications.
Cloudflare Zero Trust
Zero Trust Network Access and secure web gateway platform.
Zscaler Private Access
Cloud-native ZTNA solution providing ZTA-compliant access to private applications.
Scroll within the panel for all 10 ·
Resources
Every other property we hold for Zero Trust Architecture — documentation, portals, status pages, policies, and corporate surface — grouped by the job it does, following the integrator's arc from getting started to running in production.
Get Started 3
Portal, sign-up, and the first successful call
Documentation 5
Reference material describing how the API behaves
Design & Contract 3
Pagination, idempotency, versioning, errors, and events
Build 4
SDKs, sample code, and the tooling you integrate with
Access & Security 5
Authentication, authorization, and security posture
Other 1
Properties that don't map to a standard resource type
← All providers · Data indexed from github.com/api-evangelist/zero-trust-architecture · machine-readable index on apis.io