Framework Evaluation Tool
Articles of Zero Trust
Identity Provider Evaluation
Affirmed Identity — July 2026
NIST SP 800-207 defines Zero Trust Architecture through seven tenets that span the entire enterprise, network, workload, data, device, and identity. An identity provider does not own every tenet. But it owns the tenets that matter most: whether trust is re-evaluated every session, whether policy reacts to what is happening right now instead of a role assigned last year, and whether authentication and authorization are enforced dynamically rather than assumed. The question is whether a given identity provider actually does this, continuously, or only claims to.
Identity and Identity Monitoring, the Core of Zero Trust
Of the seven Articles below, five, Rules Two, Three, Four, Five, and Six, describe obligations that live squarely inside the identity and continuous-authentication layer: refusing to let network location stand in for trust, evaluating access per session rather than once at login, driving policy from live signals, continuously monitoring the posture of the device and identity behind every session, and strictly enforcing authentication and authorization as a dynamic, ongoing process rather than a one-time gate. Rules One and Seven describe enterprise-wide obligations, resource inventory and infrastructure telemetry, that an identity provider should feed with identity signals but cannot satisfy alone.
When evaluating an identity provider against these Articles, weight the identity-centric rules most heavily. Where the identity provider also brokers agentic AI sessions, Rule Eight, the extension to autonomous and agentic processes, applies with equal force.
Submitting that question to your favorite AI agent promptly delivers an answer. It's best done while sitting with heart medications at hand.
Try this prompt with your AI agent of choice, paste it in directly. Fill in your identity provider's product name in place of [identity provider name here] and its website domain address in place of [its website domain here]. For example: “Cisco Identity” at “https://Cisco.com” or “Entra ID” at “https://microsoft.com/”. Copy and paste the Articles of Zero Trust after “below this line”, and let the scoring begin.
Only care about identity? Scope the evaluation to identity-only Rules ↓ before copying, so the AI has nothing else to score in its answer.
Your AI Evaluation Prompt
Replace [identity provider name here] with the IdP name and [its website domain here] with the website describing it. For example “Entra ID” and “Microsoft.com”. Then copy the plain text Articles.
A review of the Articles of Zero Trust demonstrates that they are vendor-neutral and technology-agnostic, addressing the identity and monitoring principles that matter most when evaluating any identity provider. They are intended to provide an objective framework for evaluating any solution, including our own.
We welcome comments, constructive criticism, and suggestions for improving the framework as the threat landscape and Zero Trust practice continue to evolve.
Use AI to Compare Providers
Replace the [identity provider name here] and [its website domain here] with the product name and website to be compared. The Pulse CA + Sentinel and AffirmedId.com defaults can be replaced. Then copy the plain text Articles.
The Articles of Zero Trust
Each Rule identifies a specific property a Zero Trust identity architecture should exhibit. Some will be fully met by your current identity provider. Some partially. Some not at all. That's normal, and expected.
This is not a pass/fail test. It's a diagnostic. The scoring paints a picture of identity assurance and continuous monitoring, one with shades of gray in most real-world environments. What matters is seeing clearly where coverage is solid, where it's thin, and where the gaps are. You can't close a gap you are unaware of.
Notice that where a Rule is either not met or only partially so, your agent often provides hints as to why and what needs to be done to reach Achieved state.
Each Rule below is tagged with its relevance to identity provider evaluation:
Scope this evaluation
You can't control how an AI agent formats its answer, but you can control what it's asked to score. Narrow the list, the copy button, and the prompt itself to only the identity-relevant Rules, so the response doesn't bury what you care about in Rules that belong to other parts of the architecture.
Showing all Rules. The prompt and copy text below include the full standard.
Rule One — Every Resource Is In Scope
Enterprise-Wide, IdP ContributesAll data sources and computing services are resources subject to Zero Trust evaluation. No system, application, dataset, or service may be exempted from access-control scrutiny on the basis of its location, its age, or its perceived low sensitivity.
IdP relevance: An identity provider contributes by ensuring every application it protects, including its own administrative console, APIs, and integrations, is registered and governed. The completeness of the enterprise-wide resource inventory is a shared responsibility beyond the identity layer alone.
Rule Two — Location Confers No Trust
Core IdP ResponsibilityAll communication must be secured regardless of network location. Being inside a firewall, a VPN, or a corporate network segment must not, by itself, grant any degree of trust that would not otherwise be extended.
IdP relevance: This is an identity-provider decision as much as a network one: conditional-access rules that relax authentication requirements for “trusted” networks or VPN-originated traffic are a common, quiet violation of this Rule, and one only the identity provider can close.
Rule Three — Access Is Granted Per Session, Not Once and For All
Core IdP ResponsibilityAccess to an individual resource is evaluated and granted on a per-session basis. A credential, token, or authentication event valid at one moment does not carry indefinite authority; each meaningful access must be its own evaluated event.
IdP relevance: Token and session lifetime, and whether authority is re-evaluated within a session rather than only at login, are entirely identity-provider properties. This Rule sits at the center of what an identity provider is for.
Rule Four — Policy Must Be Dynamic, Not Static
Core IdP ResponsibilityAccess decisions are determined by dynamic policy, incorporating the observable state of the requesting identity, device, and application, and may incorporate behavioral and environmental attributes as well. A policy fixed at the time of role assignment and never revisited is not a Zero Trust policy.
IdP relevance: Whether an identity provider evaluates anything beyond role or group membership, device posture, behavior, location, request pattern, at the moment of a request is a direct, measurable identity-provider capability.
Rule Five — Asset Integrity Is Continuously Monitored, Never Assumed
Core IdP ResponsibilityThe enterprise monitors and measures the integrity and security posture of all assets, devices, and services on an ongoing basis. No asset is treated as compliant, patched, or uncompromised by default; that status must be continuously verified.
IdP relevance: For identity purposes, this Rule tests whether the identity provider ingests and acts on live device and identity posture signals for the duration of a session, or only checks posture once, at enrollment or login.
Rule Six — Authentication and Authorization Are Dynamic and Strictly Enforced
Core IdP ResponsibilityAll resource authentication and authorization are dynamic processes, repeated as a continual cycle of scan, evaluate, and enforce, and are strictly enforced prior to every access, with no implicit exceptions for convenience or legacy compatibility.
IdP relevance: This Rule is the identity provider's core function stated plainly: authentication and authorization, continuously repeated and automatically enforced, with no standing exceptions for legacy systems or administrative convenience.
Rule Seven — The Enterprise Collects Evidence to Improve Its Own Posture
Enterprise-Wide, IdP ContributesThe enterprise collects information about the current state of assets, network infrastructure, and communications, and uses that information to continually improve its security posture. Data collected for compliance appearances but never analyzed does not satisfy this rule.
IdP relevance: The identity provider owns the identity and access telemetry slice of this Rule outright, every authentication, authorization, and enforcement event, and should contribute it to a broader enterprise-wide feedback loop it does not control end to end.
Rule Eight — Extension to Autonomous and Agentic Processes
Core IdP ResponsibilityAutonomous and agentic processes are subjects in their own right and are therefore subject to Rules One through Seven in the same manner as any human user. An identity provider that brokers agentic AI sessions must additionally ensure traceable origin (every agent traces to an authenticated human principal), bounded inherited authority (an agent's authority never exceeds its principal's and contracts automatically as the principal's standing changes), and action-level observability (every discrete agent action is individually authorized and attributable, not merely the session as a whole).
IdP relevance: Where an identity provider issues identity to, or governs sessions for, agentic AI processes, this Rule is as central to its function as Rules Two through Six are for human sessions.
Plain Text Version (for AI Submission)
Copy this block and paste it into your AI prompt after the evaluation question above.
How Does Pulse CA Measure Up?
We built Pulse with these Rules as design requirements, not aspirational goals. Per-session evaluation, dynamic policy driven by live identity and device signals, continuous posture monitoring for the life of a session, and strictly enforced, automated authentication and authorization, these are baked into the architecture, for human and agentic sessions alike.
Ask your AI agent to score us. We're not concerned about the answer.
Request a Demo → Read the Technical BriefPulse CA™ — AffirmedID at affirmedid.com — Copyright © June 2026