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

Compliance teams usually see “token validation” framed as an engineering detail. Auditors treat it as an access control requirement: if your systems accept unverified identity assertions or access tokens, you cannot prove that the subject (user/service) is who the token says it is, or that the authorization claims (roles/scopes) are intact. IA-13(2) makes that explicit: verify source and integrity before access is granted. ¹

This requirement shows up most sharply in modern architectures: SSO (SAML/OIDC), API-to-API authentication (JWT), service-to-service mTLS with SPIFFE/SVIDs, and any environment with a centralized IdP issuing tokens consumed by many downstream services. A single “accept-any-JWT” misconfiguration can turn your identity provider into a soft spot for lateral movement.

This page gives you requirement-level implementation guidance you can assign and track: where to enforce validation, what “verify” concretely means, what artifacts to retain, and the audit questions that commonly expose gaps. The goal is fast operationalization with evidence you can produce on demand.

Regulatory text

Requirement (IA-13(2)): “The source and integrity of identity assertions and access tokens are verified before granting access to system and information resources.” ¹

Operator meaning: Every system that relies on an identity assertion (for example, SAML assertion) or access token (for example, OAuth2 access token / JWT) must validate that:

1. the token/assertion came from a trusted issuer (source), and
2. it has not been altered and is still valid (integrity),
   before the system authorizes any action or access to data. ¹

Plain-English interpretation

IA-13(2) is a “don’t trust the envelope” rule. Your apps and infrastructure cannot accept a bearer token or identity assertion at face value. They must verify cryptographic authenticity (signature/certificate chain), expected issuer, intended audience, and validity constraints (time, nonce/jti where applicable) prior to granting access.

If your environment uses an API gateway, ingress controller, service mesh, or shared authentication middleware, the simplest compliance posture is to standardize validation there and block traffic that fails checks. If validation happens inconsistently across services, you will struggle to prove the control operates.

Who it applies to

Entities

• Federal information systems and contractors handling federal data that adopt NIST SP 800-53 as a control baseline. ²

Operational contexts where IA-13(2) is “in scope”

• Workforce SSO: SAML assertions consumed by SaaS, VDI, internal apps.
• Customer identity / CIAM: OIDC tokens consumed by web/mobile backends.
• API security: OAuth2/JWT access tokens presented to APIs.
• Microservices: service-to-service tokens, signed identity documents, or mesh-issued identities.
• Third-party integrations: inbound tokens/assertions from partners, brokers, or external IdPs (bring-your-own-IdP scenarios).

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

1) Build an inventory of “relying parties”

Create a list of every system component that accepts identity assertions or access tokens:

• API gateway / WAF / ingress
• Web apps and mobile backends
• Internal APIs and microservices
• Message consumers (queues/streams) that accept token-bearing messages
• Admin consoles and automation tools

Deliverable: “Token and Assertion Relying Party Register” with owner, environment, and enforcement point.

2) Define what “verified” means in your standard

Write a short standard (one page is enough) that each relying party must meet. Include:

• Accepted token types (SAML, JWT access token, JWT ID token, opaque tokens with introspection)
• Allowed issuers (exact issuer identifiers)
• Required signature validation method (JWKS, certificate pinning where appropriate)
• Required claims checks:
  • issuer (iss) matches allowlist
  • audience (aud) matches the relying party
  • expiration (exp) and not-before (nbf) enforced with clock skew rules
  • subject (sub) present and correctly formatted
  • scopes/roles validated against authorization policy
• Revocation approach:
  • opaque token introspection OR short-lived JWTs plus key rotation controls
• Rejection behavior: fail closed; return appropriate auth error; do not downgrade to anonymous access

Tip for operators: Treat this as a “validation contract” that engineering teams implement and security reviews test.

3) Centralize enforcement where you can

Aim for a small number of enforcement points:

• North-south traffic: API gateway validates tokens and passes identity context downstream (headers are signed or passed in a trusted channel only).
• East-west traffic: service mesh or shared library validates tokens for internal calls, or use mTLS identities and exchange for workload tokens at the edge.

Compliance angle: Centralizing reduces variance and audit scope. It also makes evidence collection easier.

4) Establish issuer trust and key lifecycle controls

Verification depends on keys and trust anchors.

• Maintain an allowlist of trusted issuers (your IdP(s), approved third-party issuers).
• Define how signing keys are fetched (JWKS URL) and cached.
• Define rotation expectations and failure modes:
  • what happens when keys rotate
  • what happens when JWKS endpoint is unavailable
• Restrict who can add a new issuer or change JWKS endpoints. Track it as a security-impacting change.

Control owner: IAM or Security Engineering, with Change Management oversight.

5) Implement claim validation and binding to authorization

Make sure the token’s claims map to what the app authorizes.

• Validate scopes/roles against an internal policy (RBAC/ABAC).
• Prevent privilege escalation via untrusted claims:
  • do not accept “role=admin” from an untrusted issuer
  • do not accept unsigned or self-signed tokens
• If you rely on groups, document how group membership is asserted and validated.

Common audit gap: Teams validate signature and expiry, then blindly trust authorization claims without constraining them to the app’s allowed values.

6) Add negative testing and continuous control checks

Build tests that prove the system rejects:

• tokens with invalid signatures
• tokens from the wrong issuer
• tokens with wrong audience
• expired tokens
• tokens missing required claims
• tokens with manipulated scopes/roles

Run these as:

• pre-deployment automated tests for each relying service
• periodic control health checks in production (synthetic tests or sampled log review)

This aligns with the operational expectation that controls are not “set once and forget.” ²

7) Log verification outcomes (without leaking secrets)

To prove operation and support incident response:

• Log token verification failures with reason codes (invalid signature, bad issuer, expired).
• Avoid logging full tokens or sensitive claims.
• Retain logs per your retention policy and make them searchable for audits.

8) Document exceptions and compensating controls

Some legacy systems cannot validate modern tokens.

• Require a documented exception with time-bound remediation.
• Add a compensating control (for example, validate at a gateway in front of the legacy app and block direct access).

Required evidence and artifacts to retain

Auditors will ask for proof that validation occurs “before granting access.” Build an evidence bundle you can produce quickly:

Evidence item	What it proves	Examples
Token/assertion validation standard	Your definition of “verified”	One-page engineering standard and security policy mapping
Relying party register	Coverage and ownership	System list with owners and enforcement points
Config snapshots	Enforcement is enabled	API gateway JWT validation config, JWKS settings, allowed issuers/audiences
Secure code patterns	App-level verification	Auth middleware code snippets or approved libraries configuration
Test results	Control works in practice	CI test outputs for invalid issuer/audience/expiry/signature
Change records	Integrity of trust configuration	Tickets/approvals for issuer allowlist and key endpoint changes
Log samples	Runtime enforcement	Redacted logs showing rejected invalid tokens and accepted valid ones

Daydream (or a similar GRC system) is useful here because you can attach the minimum evidence bundle to the requirement, assign owners per relying party, and track control health checks and remediation to closure without chasing files across teams.

Common exam/audit questions and hangups

Expect these questions in SOC 2-style testing, federal assessments, and customer due diligence:

1. “Where is verification enforced?” Show the enforcement point(s) and why traffic cannot bypass them.
2. “How do you know the issuer is trusted?” Provide the issuer allowlist and change approvals.
3. “Do you validate audience and expiry?” Demonstrate required claim checks in config/tests.
4. “How do you handle key rotation?” Show your JWKS retrieval/caching and rotation readiness evidence.
5. “Can a service accept tokens directly?” If yes, show it uses the standard library and has tests.
6. “Do logs prove decisions?” Provide samples of allow/deny outcomes tied to verification checks.

Frequent implementation mistakes (and how to avoid them)

• Accepting tokens without checking aud. Fix by enforcing audience per relying party and testing wrong-audience rejection.
• Relying on “algorithm=none” safe defaults. Fix by explicitly allowing only expected algorithms and rejecting unsigned tokens.
• Trusting identity headers from upstream without a trusted channel. Fix by validating tokens at the service or cryptographically protecting identity propagation.
• No formal issuer onboarding. Fix by requiring security review and change control for new issuers/JWKS endpoints.
• Logging full tokens. Fix by logging a token hash/jti and failure reason, not the bearer token.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat “enforcement” primarily as assessment and audit risk rather than a case-law-driven issue.

Practically, IA-13(2) failures map to high-impact attack paths:

• Token forgery or substitution if signature/issuer checks are weak.
• Privilege escalation if scopes/roles are not constrained.
• Lateral movement across microservices if internal relying parties do not verify tokens consistently.

For a CCO or GRC lead, the risk is twofold: (1) unauthorized access to federal data or regulated information, and (2) inability to demonstrate control operation with evidence tied to real enforcement points. ²

A practical 30/60/90-day execution plan

First 30 days: Establish coverage and a minimum standard

• Assign an IA-13(2) control owner (IAM/Security Engineering) and a compliance owner (GRC).
• Produce the relying party register for tokens/assertions.
• Publish the token/assertion validation standard (issuer, signature, audience, expiry, required claims).
• Identify the primary enforcement points (gateway/mesh/middleware) and confirm they are enabled for the highest-risk entry points.

Days 31–60: Prove it works and close the bypass paths

• Implement or standardize validation in the gateway and top relying services.
• Add negative tests to CI for representative services.
• Implement logging for verification outcomes with safe redaction.
• Create an exception process for legacy systems, including compensating controls and remediation tracking.

Days 61–90: Operationalize and make it auditable

• Run a control health check cycle: sample services, validate configs, execute negative tests, collect artifacts.
• Tighten change control around issuer onboarding and JWKS endpoint changes.
• Build a repeatable evidence bundle in Daydream: register, standard, configs, test outputs, log samples, exceptions, and remediation tickets.
• Prepare an “auditor packet” that answers the common questions with direct links to evidence.

Frequently Asked Questions

Does IA-13(2) require JWTs specifically?

No. It applies to identity assertions and access tokens in whatever form you use, including SAML assertions, JWTs, and opaque tokens. The consistent requirement is to verify source and integrity before granting access. ¹

If our API gateway validates tokens, do services still need to validate them?

You can centralize validation, but you must prevent bypass. Document the architecture and controls that make it impossible (or tightly controlled) for traffic to reach services without passing the gateway, then test that assumption.

What counts as “verifying integrity” for an access token?

Integrity means you can detect tampering and invalidity before authorization. In practice, that means signature validation (or introspection for opaque tokens) plus required claim checks like issuer, audience, and expiry. ¹

How should we handle third-party identity providers or partner-issued tokens?

Treat each external issuer as a formal onboarding event with security review, an explicit allowlist entry, and documented key retrieval/rotation method. Keep evidence of approval and the relying parties that accept that issuer.

Are logs required for IA-13(2)?

The control text does not prescribe logging, but logs are one of the fastest ways to prove the verification decision happened before access. If you do log, avoid recording full bearer tokens and focus on reason codes and identifiers. ¹

What evidence is most persuasive in an audit?

Configurations that show validation is enabled at enforcement points, plus test results proving invalid tokens are rejected. Pair that with a relying party register and change records for issuer/key configuration to show sustained operation.

Footnotes

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

2. NIST SP 800-53 Rev. 5