Quick-reference card
| Field | Value |
|---|---|
| Control ID | IA-13 |
| Control Name | Identity Providers and Authorization Servers |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | Identification and Authentication |
| Baselines | --- |
| Relevance | First Party and Third Party (Organization and System Level) |
| Risk Severity | High |
What this control requires
IA-13 requires organizations to deploy identity providers and authorization servers that centrally govern user, device, and service identities. Rather than letting each application handle its own authentication logic, this control mandates a dedicated identity infrastructure layer — built around identity providers (IdPs) and authorization servers — that issues assertions and access tokens to verified entities, including non-person entities (NPEs).
In practice, this means standing up or configuring services that act as the single source of truth for who (or what) is allowed to access a given resource. Identity providers manage authenticators and identity assertions, while authorization servers create and issue access tokens that grant scoped access to systems or data. Single sign-on (SSO) platforms are a common example of services that combine both functions.
But without centralized identity and authorization services, organizations end up with fragmented credential stores, inconsistent authentication policies, and access decisions that no one can audit in aggregate. NIST added IA-13 in Revision 5.1.1 of the SP 800-53 framework specifically to address the growing reliance on federated identity architectures and token-based access models across modern enterprise environments.
Why it matters
Most organizations already use identity providers and authorization servers in some form, but few treat them as formally controlled infrastructure. The gap between “we have SSO” and “we govern our IdP and authorization server configuration as auditable controls” is where compliance risk concentrates.
The result is real audit exposure: failure to formally implement IA-13 may lead to certification withdrawal or regulatory findings during assessments. Because this control isn’t part of any baseline, auditors examining it are typically evaluating organizations that have voluntarily adopted it or are subject to tailored security plans. That scrutiny tends to be detailed and evidence-driven.
Specifically, identity providers and authorization servers sit at the center of every access decision, which means a single misconfiguration radiates outward. A misconfigured IdP can silently grant access to the wrong entities, while an authorization server issuing overly broad tokens can undermine the principle of least privilege across every connected system.
Where this breaks down further is in the broader IA control family that rely on federated identity assertions. If your vendors’ IdPs aren’t properly validated, their authentication weaknesses become your authorization gaps.
What attackers exploit
- Token theft and replay attacks. Stolen or intercepted access tokens let attackers impersonate legitimate users without ever touching a password. Weak token management, including long-lived tokens and missing revocation mechanisms, expands the attack window.
- IdP misconfiguration. Overly permissive identity provider settings, such as accepting assertions from untrusted sources or failing to validate assertion signatures, let adversaries forge identity claims.
- Assertion manipulation. Attackers who can modify identity assertions in transit (through weak cryptographic protections or missing integrity checks) can elevate privileges or bypass multi-factor authentication controls entirely.
- Orphaned service accounts and NPE identities. Non-person entities like API keys, service principals, and machine identities are often excluded from regular access reviews, creating persistent backdoors.
How to implement
The most common failure mode with IA-13 isn’t the absence of identity infrastructure. It’s the gap between deploying an IdP or authorization server and actually governing it as a controlled, auditable component of your security architecture.
For your organization
Start by inventorying every identity provider and authorization server in your environment, including cloud-hosted IdPs, on-premises directory services, and any application-level authentication services that issue tokens or assertions. Many organizations discover shadow IdPs operating outside central IT governance during this step, particularly in environments where individual business units have adopted their own cloud-based authentication services.
In practice, this means defining and documenting your organization’s policies for identity provider and authorization server management. Your identification and authentication policy should specify which IdPs are authorized, what assertion formats are accepted, how token lifetimes are configured, and what cryptographic protections are required for assertions and tokens.
Specifically, implement the following technical controls:
- Configure IdPs to manage user, device, and NPE identities with attribute-based access controls that support both authentication and authorization decisions.
- Ensure authorization servers issue scoped access tokens with appropriate lifetimes and revocation capabilities.
- Validate all identity assertions cryptographically. Reject unsigned or improperly signed assertions.
- Integrate IdP and authorization server logs into your centralized security monitoring to detect anomalous authentication patterns.
The result is a documented review program for your identity infrastructure. Audit IdP configurations quarterly, review token lifetimes and scoping policies, and verify that NPE identities undergo the same access review processes as human users. Document each review cycle as evidence for assessors.
Where this breaks down is when teams treat SSO deployment as sufficient compliance without documenting the underlying access control policies. Other common mistakes include failing to include non-person entities in identity governance, neglecting to test assertion validation by attempting to submit forged or expired tokens, and allowing authorization servers to issue tokens with no audience restriction. Teams that skip the inventory step in particular tend to discover during assessments that shadow IdPs were issuing assertions outside any documented governance process.
For your vendors
When evaluating third-party compliance with IA-13, your security questionnaires should target the specific infrastructure and governance practices this control demands. Many vendors will claim SSO compliance without distinguishing between identity provider and authorization server functions, so your questions need to surface that distinction.
Specifically, ask vendors to identify every identity provider and authorization server they operate, including cloud-based and on-premises services. Request documentation showing how these systems manage user, device, and NPE identities, attributes, and access rights.
Key questions for your questionnaire:
- What identity providers does your organization use, and are they centrally managed under a documented policy?
- How are access tokens scoped, issued, and revoked by your authorization servers?
- What cryptographic protections do you apply to identity assertions and access tokens?
- How do you manage non-person entity identities (service accounts, API keys, machine identities)?
- What is your review cadence for IdP and authorization server configurations?
In practice, this means requesting the vendor’s identification and authentication policy, system security plan sections covering IdP and authorization server architecture, and configuration documentation showing token lifetime and scoping settings. You should also ask for logs or audit reports from recent identity infrastructure reviews to verify that governance is active, not just documented.
Where this breaks down is when vendors can’t distinguish between their identity providers and their authorization servers, or when token lifetimes exceed 24 hours without documented justification. Other red flags include the absence of NPE identity management, no evidence of periodic configuration reviews, and authorization servers that issue tokens without audience restrictions or revocation capabilities. If a vendor describes their SSO deployment but can’t produce the underlying policy governing it, the control likely isn’t formally implemented.
Take token management as a specific verification step. Ask the vendor to demonstrate how they revoke access tokens when an employee departs or a service account is decommissioned. Vendors with mature IA-13 implementations can show a documented process and point to audit logs that confirm it was followed. Vendors who hesitate or defer to “we’ll handle it when it comes up” are operating without the governance this control requires.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Identification and authentication policy | Policy document defining authorized IdPs, accepted assertion formats, token lifetime standards, and cryptographic requirements for identity assertions |
| System security plan | SSP sections describing the identity provider and authorization server architecture, including integration points and data flows |
| System design documentation | Architecture diagrams showing IdP and authorization server placement, federation trust relationships, and token issuance workflows |
| Configuration settings | Screenshots or exports of IdP configuration showing assertion signing requirements, token scoping rules, and NPE identity management settings |
| Access review records | Audit logs and review reports documenting quarterly IdP configuration reviews and NPE identity access reviews |
| Procedures documentation | Operational procedures for onboarding new identity providers, rotating cryptographic keys, and revoking compromised tokens |
Cross-framework mapping
No applicable content for this control.
Related controls
- AC-03 (Access Enforcement) defines how systems enforce approved authorizations, directly consuming the access tokens and identity assertions that IA-13’s infrastructure produces.
- IA-02 (Identification and Authentication of Organizational Users) covers how organizational users prove their identity, which feeds into the identity provider managed under IA-13.
- IA-03 (Device Identification and Authentication) addresses device-level identity verification, relevant because IA-13 requires IdPs to manage device identities alongside user and NPE identities.
- IA-08 (Identification and Authentication of Non-organizational Users) extends identity requirements to external users, whose authentication often relies on federated IdP assertions governed by IA-13.
- IA-09 (Service Identification and Authentication) governs how services authenticate to other services, overlapping with IA-13’s non-person entity identity management requirements.
- IA-12 (Identity Proofing) establishes the process for verifying an entity’s claimed identity before credentials are issued, operating upstream of the identity providers managed under IA-13.
Frequently asked questions
What is NIST SP 800-53 IA-13?
IA-13 requires organizations to deploy and govern identity providers and authorization servers that centrally manage user, device, and non-person entity identities, attributes, and access rights. Added in Revision 5.1.1, this control formalizes the infrastructure behind federated authentication and token-based authorization. Organizations must ensure their IdPs issue validated identity assertions and their authorization servers create properly scoped access tokens for all entity types.
What happens if IA-13 is not implemented?
Without IA-13, identity assertions and access tokens are issued without centralized governance, leaving authentication and authorization decisions fragmented across individual systems. Auditors assessing your system security plan will flag the absence of documented IdP and authorization server controls as a gap. The operational consequence is that token misuse, orphaned NPE identities, and unvalidated assertions go undetected because no single control point exists to enforce consistent policies.
How do you audit IA-13?
Auditing IA-13 starts with verifying that identity providers are employed to manage user, device, and NPE identities supporting both authentication and authorization decisions. Assessors review the identification and authentication policy, system design documentation showing IdP and authorization server architecture, and configuration settings confirming assertion validation and token scoping. They also check that authorization servers are producing properly scoped access tokens and that periodic reviews of the identity infrastructure are documented.
What is the difference between an identity provider and an authorization server?
An identity provider (IdP) verifies who or what an entity is and issues identity assertions attesting to that identity. An authorization server determines what a verified entity is allowed to access and issues access tokens granting scoped permissions to specific resources. In many deployments, a single platform like an SSO solution performs both functions, but IA-13 treats them as distinct capabilities because they serve different assessment objectives. Your identification and authentication policy should document the governance of each function separately, even when they share the same underlying platform.