User and device
- SSO with OpenID Connect or SAML
- Phishing-resistant MFA such as passkeys
- Device signals where you manage devices
Zero Trust Architecture
Zero trust architecture for applications
Many applications still trust any request that comes from inside the network. Agnotic Technologies builds zero trust into the applications and cloud environments we deliver, so every user and service proves who it is on every request.
NIST SP 800-207Identity on every requestWorkload identity and mTLSSegmented cloud networks
Trusted by global innovators
Zero trust
What is zero trust architecture for an application?
Zero trust architecture is a security design in which no user, device or service is trusted because of where it sits on the network; every request is authenticated and authorized. Agnotic Technologies builds zero trust into the applications and cloud environments we deliver, following NIST SP 800-207: identity on every request, workload identity, mutual TLS and segmentation.
Zero trust is not a product you install. It is a set of design decisions in your code, identity setup and cloud account, and we build those decisions for you rather than resell tools.
Controls specific to protected health information, such as PHI access rules and audit, are covered on our PHI data security page.
Tenets to controls
How do the NIST SP 800-207 tenets map to application controls?
Each tenet, the control we build for it and the evidence it leaves for your auditors and customers.
| NIST SP 800-207 tenet | Application or cloud control | Evidence it leaves |
|---|---|---|
| All data sources and computing services are resources | Every service, API, queue and data store defined in infrastructure as code | A resource inventory generated from code |
| All communication is secured regardless of network location | TLS on every connection, mutual TLS between services, no plaintext listeners | Certificate inventory and configuration scans |
| Access is granted per session | Short-lived tokens and sessions, no long-lived shared API keys | Token lifetimes in configuration and key rotation records |
| Access is decided by dynamic policy | A policy engine checking user, role, tenant, resource and context on each request | Policies in version control with tests |
| The enterprise monitors the security posture of its assets | Patched base images, dependency scanning and posture checks in the pipeline | Scan reports and image provenance |
| Authentication and authorization are enforced before access | Enforcement at the gateway and inside each service; phishing-resistant MFA for staff | Denied request logs and MFA policy settings |
| The enterprise collects data to improve its security | Central logs and traces of every access decision | Searchable decision logs in your SIEM |
Decision and enforcement points
Where do policy decision and enforcement points sit in an application?
NIST SP 800-207 separates the policy decision point from the policy enforcement point. This is where each one lives in the applications we build.
Edge enforcement
- API gateway or identity-aware proxy validating tokens
- Web application firewall and rate limits
Policy decision
- Central policy engine, such as Open Policy Agent or Cedar
- Decisions on role, tenant, resource and context
Service enforcement
- Each service checks authorization per request and per record
- No service trusts a call just because it is internal
Workload identity
- Short-lived service identities, such as cloud IAM roles or SPIFFE IDs
- Mutual TLS, often through a service mesh
Data and telemetry
- Encryption keys scoped per service
- Decision logs and traces sent to your SIEM
What do we build into a zero trust application?
The controls we design and build, inside your code and cloud account.
Identity and SSO
One identity provider for staff and customers' admins, with phishing-resistant MFA for privileged access.
Per-request authorization
Authorization rules written as policy code, tested like application code and checked on every request.
Workload identity and mTLS
Every service gets its own short-lived identity and talks to others over mutual TLS.
Cloud network segmentation
Private subnets, security groups per service and private endpoints, so a compromised service reaches as little as possible.
Secrets and keys
No static credentials in code or configuration; secrets come from a managed store and keys are scoped per service.
Logging and detection
Every access decision, allowed or denied, logged with enough context to investigate.
Roadmap
How do we stage a zero trust roadmap?
We order the work by the pillars of CISA's Zero Trust Maturity Model, starting where risk is highest.
Identity
SSO everywhere and phishing-resistant MFA for administrators and engineers first.
Applications and workloads
Per-request authorization in each service, and a workload identity for every service.
Networks
Segmentation in the cloud account, private endpoints and mutual TLS between services.
Data
Data classified by sensitivity, encrypted with scoped keys and access logged.
Devices
Device posture checks for administrative access, where your organization manages devices.
Visibility, automation and governance
Decision logs, alerts and policy changes reviewed like code, across every pillar.
Failure points
Where do zero trust efforts fall short in applications?
Gaps we find when we review applications that are described as zero trust.
Challenge
Authorization happens only at the gateway, and services trust every internal call.
Agnotic approach
Each service checks the caller's identity and permissions itself.
Challenge
Services share one account or a long-lived key.
Agnotic approach
One identity per service, with short-lived credentials issued automatically.
Challenge
The cloud network is flat, so one compromised service can reach everything.
Agnotic approach
Segments per service tier, with only the connections each service needs.
Challenge
MFA is on, but administrators still use SMS codes.
Agnotic approach
Phishing-resistant authenticators for privileged roles, such as passkeys or security keys.
Challenge
Authorization rules are scattered through the codebase.
Agnotic approach
Rules move into policy code that can be reviewed, tested and audited in one place.
Challenge
Logs record requests but not the access decisions.
Agnotic approach
The policy engine logs each decision with the inputs it used.
Who it is for
Who asks us for zero trust architecture?
Teams whose customers, auditors or own risk reviews ask how access is controlled inside the application.
SaaS companies selling to enterprises
Products that need to answer detailed questions about internal access and service-to-service security.
Healthcare and fintech products
Applications holding sensitive data, where internal access must be limited and logged.
Teams moving off VPN-based access
Internal tools and admin consoles moved behind identity-aware access instead of a network perimeter.
Microservice platforms
Systems where many services talk to each other and need identity, mTLS and per-request checks.
Zero trust security for startups
Young products that build identity and segmentation in from the start, which costs far less than adding it later.
Frameworks
Frameworks we design zero trust against
Public frameworks behind the table and roadmap above.
NIST SP 800-207CISA ZTMM 2.0NIST SP 800-63B-4NIST SP 1800-35OpenID Connect
Facts and sources
Facts behind zero trust architecture
Standards that define zero trust, each linked to its primary source.
NIST SP 800-207, Zero Trust Architecture (August 2020), states that zero trust grants no implicit trust to assets or user accounts based on network location or asset ownership, and that authentication and authorization happen before a session to a resource is established.
Source: NIST SP 800-207 (NIST CSRC)A NIST SP 800-207 tenet is that access to each resource is granted per session with the least privilege needed, and authenticating to one resource does not automatically grant access to another.
Source: NIST SP 800-207, section 2.1 (NIST)CISA's Zero Trust Maturity Model Version 2.0 has five pillars and three cross-cutting capabilities, and describes traditional, initial, advanced and optimal stages within each pillar.
Source: Zero Trust Maturity Model (CISA)NIST SP 800-63B-4 (July 2025) requires verifiers to offer at least one phishing-resistant authentication option at AAL2, and AAL3 requires a phishing-resistant authenticator with a non-exportable key.
Source: NIST SP 800-63B-4 (NIST)NIST SP 1800-35 (June 2025) documents 19 example zero trust implementations that the NCCoE built with 24 collaborators to show how the SP 800-207 architecture works with available technology.
Source: NIST SP 1800-35 (NIST CSRC)
Scope and cost
What drives the cost of zero trust architecture?
We price zero trust work per engagement, not from a list. These factors set the size of it.
Number of services
How many services need workload identity, mTLS and their own authorization checks.
Identity setup
How many identity providers, user types and administrative roles are involved.
Legacy applications
Older applications that cannot easily check tokens and need a proxy in front of them.
Cloud accounts
How many accounts and networks need segmentation and private endpoints.
Logging and SIEM
Where decision logs go and what your security team needs to see.
Compliance scope
Controls your customers or regulators expect evidence for, such as SOC 2 or HIPAA.
Engagement
How does a zero trust engagement work?
From the tenet review to controls across every service.
1.
Review against the tenets
We review your applications and cloud setup against the tenet table and agree the first slice of work.
Review2.
First enforcement slice
Identity, policy and enforcement built for one critical service end to end, with decision logs.
Build3.
Roll out by pillar
We extend the pattern across services, networks and data, and support your team as it takes ownership.
ExtendFrequently Asked Questions
No. Vendors sell tools that help, but zero trust is an architecture: identity, authorization, encryption and segmentation decisions in your applications and cloud. We design and build those decisions for you; we do not resell security products.
Not on day one. Many teams keep the VPN while internal tools move behind identity-aware access one at a time. The VPN stops being the thing that grants trust long before it is switched off.
Each service gets its own short-lived identity, connections use mutual TLS, and each service checks whether the calling service and user may perform the action. Being on the same network grants nothing.
Authentication that a fake login page cannot capture and replay, such as passkeys or hardware security keys bound to the real site. NIST SP 800-63B-4 requires it at AAL3 and requires verifiers to offer it at AAL2.
With identity: SSO and phishing-resistant MFA for administrators and engineers. Then per-request authorization in your most sensitive service, because that is where an attacker who gets inside does the most damage.
It supports the access control, encryption and logging controls both expect, and the tenet table gives you evidence for each one. It does not replace an audit, and we make no certification claims for you.
There is no package price, because it scales with your system: the number of services, your identity setup, legacy applications that need a proxy, cloud accounts and logging needs.