IA-13(2): Verification of Identity Assertions and Access Tokens

The ia-13(2): verification of identity assertions and access tokens requirement sits in the gap between “someone authenticated somewhere” and “your system should grant access.” In modern environments, identity is often conveyed through SAML assertions, OAuth 2.0 access tokens, OpenID Connect ID tokens, session cookies, or service-to-service credentials minted by an identity provider (IdP), authorization server, or cloud platform. IA-13(2) is the control that forces your applications, APIs, and infrastructure to treat those artifacts as untrusted until validated.

Practically, this requirement shows up during SSO deployments, API gateway rollouts, zero trust initiatives, and any integration where a third party or centralized platform vouches for a user or workload. Auditors look for one thing: can an attacker present a forged, replayed, mis-scoped, or tampered token/assertion and still get in?

This page gives requirement-level implementation guidance you can hand to engineering and IAM teams. The goal is fast operationalization: define what must be verified, where verification must occur, how to configure trust and keys, what logs prove it works, and what evidence closes the audit loop. The requirement text is concise; the work is in making verification consistent across every entry point. ¹

Regulatory text

Requirement: “The source and integrity of identity assertions and access tokens are verified before granting access to system and information resources.” ²

Operator meaning (what you must do):

1. Verify “source”: accept assertions/tokens only from approved issuers (trusted IdPs/authorization servers) and only through expected trust paths (metadata, certificates, keys, tenant boundaries).
2. Verify “integrity”: ensure the assertion/token was not modified in transit or at rest, typically via cryptographic verification (e.g., signature validation) and transport protections.
3. Do it before access: verification must happen in the enforcing component (application, API gateway, reverse proxy, service mesh, or policy enforcement point) prior to authorizing any action or returning protected data. ²

Plain-English interpretation

Your systems must treat identity artifacts as potentially forged until proven otherwise. If your app accepts a JWT, the app (or a fronting control like an API gateway) must verify the signature and validate key claims (issuer, audience, expiration, and scope) every time. If your app consumes a SAML assertion, it must validate the signature and confirm it came from your trusted IdP and matches your configuration.

This control is commonly missed in microservices and “internal” APIs. Teams assume the perimeter is trusted, then pass tokens around without verifying them at each boundary. IA-13(2) pushes you to define where verification occurs and to make that enforcement consistent, measurable, and provable. ¹

Who it applies to

Entities:

• Federal information systems.
• Contractor systems handling federal data. ²

Operational contexts (where you should scope it in):

• SSO and federation (SAML/OIDC).
• API authorization (OAuth access tokens, JWTs).
• Service-to-service auth (workload identity, signed service tokens).
• Third-party integrations where an external identity provider asserts identity.
• Privileged access flows (admin consoles, break-glass paths), where token misuse has outsized impact.

Systems and components in scope:

• Applications and APIs (public and internal).
• API gateways / reverse proxies.
• Identity middleware libraries and authentication handlers.
• Logging/SIEM pipelines that capture verification outcomes.
• Key management / trust stores used to validate issuers.

What you actually need to do (step-by-step)

Step 1: Build an “assertions and tokens inventory”

Create a simple table and keep it current:

• Entry point (app, API, gateway, workload endpoint)
• Artifact type (SAML assertion, JWT access token, OIDC ID token, session cookie)
• Issuer (IdP/authorization server)
• Validation location (gateway vs app vs sidecar)
• Key source (metadata URL, JWKS endpoint, certificate pinning method)
• Failure behavior (deny, redirect to login, error code) This inventory becomes your audit map for IA-13(2). ²

Step 2: Define non-negotiable validation rules (your minimum bar)

For JWT/OAuth/OIDC flows, require:

• Signature validation using approved algorithms and trusted keys.
• Issuer (“iss”) allowlist: match expected issuer exactly.
• Audience (“aud”) validation: token must be meant for this API/app.
• Lifetime validation: expiration enforced; reject tokens that are not yet valid if you use “nbf”.
• Scope/claims validation: required scopes/roles present for the requested action.
• Replay resistance where applicable: avoid accepting the same token in unintended contexts; enforce nonce/state for interactive OIDC where relevant.

For SAML flows, require:

• Signed assertions (or signed responses per your architecture) and signature verification against trusted IdP certs.
• Strict audience restriction and recipient/ACS URL matching.
• Time validity enforcement (conditions/not-on-or-after).
• Subject confirmation checks appropriate to your flow.

Document these as control requirements in an engineering-facing standard. Keep them short and testable. ²

Step 3: Centralize verification where it reduces variance

Pick the enforcement point(s) you can keep consistent:

• API gateway / reverse proxy: validate tokens before requests reach services.
• Service mesh / sidecar policy: validate service-to-service identity at the edge of each workload.
• Application middleware: validate tokens in code when gateway enforcement is not possible.

A common operating model is “gateway validates, apps authorize.” If you choose this, write it down and make it enforceable through architecture standards and CI/CD checks. ¹

Step 4: Lock down trust configuration and key management

Verification fails in practice when trust is loosely configured. Minimum expectations:

• Maintain an approved issuer list and ownership for changes.
• Control how signing keys are fetched (e.g., JWKS/metadata URLs) and require TLS.
• Define key rotation handling (planned rotations, emergency revocation).
• Prevent algorithm confusion or “none” algorithms through library configuration and testing.
• Ensure environments (dev/test/prod) do not share issuers/keys unless explicitly designed that way.

Tie changes to standard change management: ticket, approval, testing evidence, and deployment record. ²

Step 5: Implement “deny on verification failure” and make it observable

Your enforcement components must:

• Return a clear deny outcome on invalid signature/claims.
• Log verification failures with enough detail to investigate (issuer, reason, endpoint, correlation ID), without logging sensitive token contents.
• Alert on patterns that indicate token forgery, replay, or misconfiguration (sudden spikes in signature failures, unknown issuer attempts).

Decide what “good logs” mean for your environment, then test that logs arrive in the SIEM and are reviewable. ¹

Step 6: Test it like an attacker would

Build a small negative-test suite:

• Tamper with token payload and confirm denial.
• Change issuer/audience and confirm denial.
• Use expired token and confirm denial.
• Attempt algorithm downgrade if your stack could allow it.
• Present a token minted for one API to another API and confirm denial.

Retain test evidence per release or per significant change. ²

Required evidence and artifacts to retain

Auditors assess IA-13(2) through design proof plus operational proof. Keep:

• Token/assertion inventory (systems, artifact types, issuers, validation points).
• Standard/config baseline for token validation (required claims, issuer allowlists, audience rules).
• Configuration exports/screenshots from gateway/IdP/app middleware showing signature verification enabled and issuer/audience checks configured.
• Key/trust artifacts: metadata/JWKS configuration, certificate trust store approach, rotation procedure.
• Change records for issuer/key changes (tickets, approvals, deployment references).
• Logs showing verification outcomes (success/failure counts, sampled events).
• Test results from negative testing (tampered token rejected, wrong audience rejected).
• Exception register for any endpoint not enforcing validation, with compensating controls and sunset date. ²

Daydream (or any control management system you already run) fits best here as the system of record: control owner, implementation procedure, and recurring evidence artifacts mapped to IA-13(2), so you can produce the evidence package without rebuilding it every audit cycle. ²

Common exam/audit questions and hangups

Expect these questions and prepare short, evidence-backed answers:

• “Where exactly is token validation performed?” Show architecture diagrams and gateway/app configs.
• “How do you ensure tokens are only accepted from approved issuers?” Provide issuer allowlist and change control history.
• “How do you validate integrity?” Show signature verification settings and libraries/config.
• “What happens on validation failure?” Demonstrate deny behavior and logs.
• “How do you handle key rotation and revocation?” Provide procedure and recent rotation evidence.
• “Do internal services validate tokens, or do they trust the network?” Be explicit. “Trusted network” answers trigger deeper testing. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails IA-13(2)	Avoid it by
Accepting JWTs without validating aud	Token minted for another API can be replayed	Enforce audience per service at gateway/app
Relying on “TLS only” without signature checks	TLS protects transport, not token tampering at rest or across hops	Require signature validation for assertions/tokens
Not pinning to expected issuer	Any trusted-looking token could be accepted	Strict iss allowlist; separate by environment/tenant
Allowing weak/incorrect algorithms	Enables token forgery paths	Lock algorithms in config; add negative tests
Validating at the edge, then forwarding identity in headers without protection	Downstream services may trust spoofable headers	Use signed headers, mTLS identities, or pass tokens with re-validation
No retained evidence	Control may exist but you cannot prove it	Automate evidence pulls and store per system/release 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control. Treat it as an auditability and breach-prevention requirement: failures typically manifest as unauthorized access via token forgery, token replay across services, acceptance of tokens from the wrong issuer, or misconfigured gateways that skip validation on certain routes. IA-13(2) reduces the chance that a single misissued or tampered token becomes a systemic access failure. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign a control owner (IAM or platform security) and name engineering owners per stack.
• Complete the token/assertion inventory for critical apps and external-facing APIs.
• Identify verification gaps: endpoints that accept tokens without signature/claim validation.
• Draft your validation standard (issuer/audience/lifetime/signature requirements) and socialize it with platform teams. ²

By 60 days (implement and prove)

• Implement centralized validation at the API gateway or common middleware for the highest-risk paths.
• Add negative tests to CI/CD for at least one representative service per stack.
• Turn on logging for validation success/failure and route it to your SIEM.
• Create the evidence binder structure in Daydream (or your GRC tool): inventory, configs, test outputs, change records. ¹

By 90 days (scale and operationalize)

• Expand enforcement to remaining apps, internal APIs, and service-to-service paths.
• Formalize key rotation and issuer onboarding/offboarding procedures.
• Implement continuous checks (config drift detection where possible) and a periodic review cadence for the inventory and issuer lists.
• Close exceptions or document compensating controls with ownership and a removal plan. ²

Frequently Asked Questions

Does IA-13(2) require validating both ID tokens and access tokens?

If your systems accept either artifact to make an access decision, you must verify its source and integrity before granting access. Treat “token type” as implementation detail; the audit question is whether any identity artifact can be forged or tampered with and still work. ²

Can I satisfy IA-13(2) by validating tokens only at the API gateway?

Yes, if the gateway is the enforcement point that gates access to protected resources and downstream services do not accept alternate paths that bypass it. You still need evidence that validation is enabled on all relevant routes and that downstream services do not trust spoofable identity headers. ¹

What counts as “verifying source” in practice?

Source verification means the issuer is explicitly trusted and expected for that system, and validation keys/certificates come from controlled, approved trust configuration. Auditors will look for issuer allowlists, metadata/JWKS configuration, and change control around trust changes. ²

Do we need to store raw tokens in logs as evidence?

No. Store verification outcomes and troubleshooting metadata (issuer, audience, reason codes, correlation IDs) without retaining the full token. Keeping raw tokens can create unnecessary data exposure and is not required to prove you verified source and integrity. ¹

How do exceptions work for legacy apps that cannot validate tokens?

Track them explicitly with an exception record that states the endpoint, risk, compensating control (for example, gateway validation in front of it), owner, and removal plan. Auditors typically accept bounded exceptions with documented controls and a credible migration path. ²

What’s the fastest evidence pack to assemble for an assessment?

Provide your inventory, the written validation standard, exports/screenshots of gateway or middleware validation settings, a sample of validation logs, and negative test results that show tampered or mis-scoped tokens are denied. Tie each artifact to the IA-13(2) control record in your GRC system for clean traceability. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON