IA-13: Identity Providers and Authorization Servers

IA-13 requires you to use designated identity providers (IdPs) and authorization servers as the system’s source of truth for identities, attributes, and access rights so authentication and authorization decisions are consistent, centralized, and auditable (NIST SP 800-53 Rev. 5 OSCAL JSON). Operationalize it by standardizing protocols (for example, SAML/OIDC/OAuth), defining authoritative attribute sources, and proving enforcement across apps, APIs, devices, and non-person entities.

Key takeaways:

• Centralize authentication and authorization decisions through approved IdPs and authorization servers, not ad hoc app-local accounts (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Treat users, devices, and non-person entities (service accounts, workloads) as in-scope identities with governed attributes and access rights (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Evidence is the control: architecture, configurations, mappings, logs, and periodic access review outputs must show consistent enforcement.

IA-13: identity providers and authorization servers requirement is one of the quickest ways to expose whether your identity program is real or just policy. If each application or team can create its own identities, entitlements, tokens, and authorization logic, you inherit inconsistent access decisions, brittle offboarding, and audit gaps you cannot close with documentation alone. IA-13 pushes you toward a controlled identity plane: an identity provider for authentication and identity lifecycle, and an authorization server for issuing/verifying tokens and enforcing access decisions based on managed attributes and rights (NIST SP 800-53 Rev. 5 OSCAL JSON).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) define which IdPs and authorization servers are approved for the environment, (2) define which attributes are authoritative and where they come from, (3) require applications and APIs to integrate with them using standard protocols, and (4) retain hard evidence that access decisions actually flow through those components. This page gives requirement-level implementation guidance you can assign to IAM, Platform, and Application owners and then test like an auditor.

Regulatory text

NIST excerpt (IA-13): “Employ identity providers and authorization servers to manage user, device, and non-person entity (NPE) identities, attributes, and access rights supporting authentication and authorization decisions in accordance with {{ insert: param, ia-13_odp.01 }} using {{ insert: param, ia-13_odp.02 }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation of the text:

• “Employ identity providers” means you formally designate one or more IdPs and require systems to use them for authentication and identity attribute assertions, instead of unmanaged local accounts.
• “Employ authorization servers” means token issuance/validation and authorization flows are governed and consistent (commonly via OAuth 2.0 and OpenID Connect patterns), rather than each API inventing its own token scheme.
• “Manage user, device, and NPE identities” means humans, endpoints, servers, workloads, service accounts, bots, and integrations are all in scope for lifecycle, attributes, and access rights (NIST SP 800-53 Rev. 5 OSCAL JSON).
• The parameter placeholders in the excerpt indicate your implementation must align to organization-defined selections (for example, what protocols/architectures are approved). Your job is to define those selections and show enforcement.

Plain-English interpretation (what the requirement expects)

IA-13 expects a controlled identity and authorization architecture where:

1. identities and attributes come from approved authoritative sources,
2. authentication is performed through approved IdP(s),
3. authorization decisions are based on managed access rights and attributes, and
4. applications, APIs, and platforms integrate through approved patterns that you can test and audit (NIST SP 800-53 Rev. 5 OSCAL JSON).

If your environment still has “local users” inside critical apps, unmanaged service accounts with long-lived credentials, or APIs that accept homegrown bearer tokens, you will struggle to demonstrate IA-13.

Who it applies to

Entity scope: Federal information systems and contractor systems handling federal data commonly map to NIST SP 800-53 controls, including IA-13 (NIST SP 800-53 Rev. 5).

Operational scope (where IA-13 shows up in audits):

• Enterprise IdP and SSO stack (workforce identity, privileged identity, customer identity if applicable).
• API gateways and service-to-service authentication patterns.
• SaaS applications with separate user stores.
• Cloud IAM (workload identity, instance profiles, federated access).
• Device identity (MDM, certificates, endpoint posture where used for access decisions).
• Non-person entities (service accounts, robotic process automation users, CI/CD runners).

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

1) Declare your “approved identity and authorization plane”

Create an IA-13 standard that names:

• Approved IdP(s) for workforce and admins.
• Approved authorization server(s) (may be the same platform as the IdP) for token issuance/introspection/validation.
• Approved federation/token protocols and patterns you will accept (for example, SAML for SSO, OIDC for modern apps, OAuth 2.0 for APIs).
  Deliverable: IA-13 Architecture Standard and a System Integration Decision Tree.

2) Define authoritative identity sources and attribute governance

Document, for each identity class, the authoritative source and required attributes:

• Humans: HR system or identity directory as source of truth; include attributes like department, role, manager, employment status.
• Devices: device directory/MDM/cert authority; include device ownership, compliance state if used in policy.
• NPEs: workload identity registry, CMDB, or dedicated inventory; include owner, purpose, environment, rotation expectations, and allowed scopes.
  Deliverable: Attribute Catalog + Data Ownership (RACI) + Joiner/Mover/Leaver mappings.

3) Require application onboarding to SSO and centralized authorization patterns

Implement a gate: no production launch without:

• SSO integration to the approved IdP (interactive users).
• Central token issuance/validation path for APIs (authorization server; gateway validation rules).
• A documented mapping from roles/groups/claims to application permissions.
• A plan for break-glass access and privileged administration.
  Deliverable: IAM onboarding checklist embedded in SDLC or change management.

Practical test: pick one critical app, one SaaS app, and one internal API. Confirm each uses the approved IdP and authorization server patterns, and produce config screenshots/exports.

4) Control NPE identities like first-class identities

Most IA-13 failures happen here. Implement minimum governance for NPEs:

• Unique identity per workload/integration (avoid shared accounts).
• Clear ownership (named team) and ticket-based provisioning.
• Credential/token lifecycle: issuance, rotation, revocation.
• Scope limitation: least privilege scopes/roles; environment separation.
  Deliverable: Service account/workload identity register with owner, purpose, and access rights.

5) Enforce policy and detect bypass

Put detective controls around “shadow identity stores”:

• Scan for local users in apps where SSO is required.
• Monitor for long-lived keys/tokens where short-lived tokens are required by your standard.
• Alert on direct IAM policy edits outside the approved workflow.
  Deliverable: Exception register + detections and alerts inventory + remediation tickets.

6) Make it auditable: map control intent to evidence

A clean IA-13 implementation passes because you can prove three things:

• The architecture exists and is approved.
• Systems integrate as required.
• Access decisions and token events are logged and reviewable.
  Deliverable: IA-13 control narrative (plain language), system list in scope, and evidence map.

Daydream fit (earned mention): if you struggle to keep the evidence map current across many third parties and internal platforms, Daydream can track IA-13 control ownership, required artifacts, and recurring evidence pulls so audits do not become a scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that show design + operation:

Design evidence

• IA-13 Architecture Standard (approved IdPs/authorization servers, allowed patterns).
• Data flow diagrams for authentication and token flows (high-risk apps/APIs).
• Attribute catalog and authoritative source mapping.
• RACI for IAM ownership and app onboarding responsibilities.

Operational evidence

• IdP configuration exports or screenshots: app integrations, signing certs/keys, claim mappings.
• Authorization server configuration: token lifetimes policies (qualitative), signing algorithms, client registrations, scopes.
• Application configuration showing SSO enabled and local login disabled where required.
• Logs: authentication events, token issuance/introspection, admin changes.
• Access reviews: periodic reviews of roles/groups/claims for critical apps and NPEs (retain outputs and remediation actions).
• Exception register with approvals, compensating controls, and expiry.

Common exam/audit questions and hangups

• “Which IdP and authorization server are authoritative for this system?” Provide the standard and the specific system’s integration record (NIST SP 800-53 Rev. 5 OSCAL JSON).
• “Show me an access decision path.” Walk through: user authenticates at IdP → token/claim → API gateway validation → app role mapping.
• “How do you manage service accounts and workload identities?” Auditors expect governance, not ad hoc secrets.
• “Can a user authenticate locally if SSO is down?” If yes, show compensating controls and monitoring; if no, show documented resilience strategy.
• “How do attributes stay accurate?” Tie HR/device/NPE sources to provisioning and deprovisioning workflow.

Frequent implementation mistakes (and how to avoid them)

1. SSO added, but authorization stays local and unmanaged. Fix: require role/claim mapping documentation and periodic review for app entitlements.
2. NPE identities ignored. Fix: inventory every integration identity, assign ownership, and enforce lifecycle controls.
3. Multiple IdPs without a standard. Fix: publish the approved list and add an exception process with expiry.
4. Tokens validated inconsistently across APIs. Fix: standardize at the gateway/service mesh and ban bespoke token logic.
5. Evidence scattered across teams. Fix: create a single IA-13 evidence map and a recurring collection cadence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for IA-13. Treat IA-13 as an assessment-readiness control: gaps typically show up as audit findings, authorization to operate delays, or customer security review failures tied to inconsistent identity governance (NIST SP 800-53 Rev. 5).

Risk outcomes if IA-13 is weak:

• Orphaned access after transfers/terminations.
• Excess privileges embedded in apps because claims/roles are not governed centrally.
• Lateral movement via over-permissioned service accounts.
• Inability to demonstrate who had access, when, and why.

Practical 30/60/90-day execution plan

Use this as an operator plan; adjust to your environment.

First 30 days (stabilize and define)

• Name control owner(s) for IA-13 (IAM + Security Architecture + GRC).
• Publish the approved IdP/authorization server standard and integration patterns.
• Build the system inventory: which apps/APIs use which auth method today.
• Start the exception register for systems that cannot conform immediately.

Days 31–60 (migrate the highest-risk paths)

• Onboard top critical apps to SSO; disable local auth where feasible.
• Standardize API token validation through the authorization server/gateway.
• Stand up NPE identity register and start governing new service accounts through workflow.
• Define required evidence and assign evidence owners per system.

Days 61–90 (prove operation and close audit gaps)

• Run an access/entitlement review for critical roles/groups/claims and NPE access.
• Test offboarding: pick a sample identity, terminate it, prove access removal across integrated systems.
• Implement detective controls for bypass (local users, unmanaged tokens/keys).
• Package an IA-13 audit binder: narrative, diagrams, configurations, logs, exceptions, and review outputs.

Frequently Asked Questions

Do we need both an identity provider and an authorization server to satisfy IA-13?

IA-13 explicitly calls for both functions to manage identities/attributes and access rights supporting authentication and authorization decisions (NIST SP 800-53 Rev. 5 OSCAL JSON). In practice, a single platform can provide both, but you still need to document both roles and show systems use them.

Are service accounts and workload identities really in scope?

Yes. IA-13 includes “non-person entity (NPE) identities” alongside users and devices (NIST SP 800-53 Rev. 5 OSCAL JSON). Treat each NPE as an identity with an owner, attributes, access rights, and lifecycle controls.

What is the minimum evidence an auditor will accept for IA-13?

You need an approved standard (what IdPs/authorization servers are used), proof a sample set of systems integrates to them, and logs/configuration artifacts that show authentication and authorization decisions flow through those components (NIST SP 800-53 Rev. 5 OSCAL JSON).

We have legacy apps that cannot do SSO. Is IA-13 impossible?

No, but unmanaged local identities become an exception you must document, approve, monitor, and retire through a roadmap. Keep compensating controls tight: restricted network access, strong MFA at a jump host, and enhanced logging tied to named identities.

How do we scope “devices” for IA-13?

Scope any device identity or device attribute that influences access decisions (for example, certificate-based auth, device compliance gates, or MDM-driven conditional access). If device posture is part of authorization, your device directory/MDM becomes an authoritative attribute source you must govern.

What does “attributes and access rights” mean in real systems?

Attributes are claims or directory fields used in decisions (role, group, entitlement, device state); access rights are the resulting permissions (app roles, API scopes, IAM policies). IA-13 expects those inputs and outputs to be managed through the designated IdP and authorization server patterns (NIST SP 800-53 Rev. 5 OSCAL JSON).