PR.AA-04 Identity assertions: requirements and evidence

What PR.AA-04 identity assertions protected requires in plain terms

An auditor or customer asking how single sign-on and federated logins are protected is asking about PR.AA-04, a Subcategory in the Identity Management, Authentication, and Access Control (PR.AA) Category of the PROTECT Function in NIST CSF 2.0. NIST's paraphrased outcome is that identity assertions are protected, conveyed and verified. An identity assertion is the signed statement, such as a SAML assertion or an OpenID Connect ID token, that an identity provider issues to tell a relying application who the user is and what they may access. PR.AA-04 is new in CSF 2.0. The NIST CSF 1.1 to 2.0 Core Transition Changes spreadsheet shows that its topic was not clearly present in any CSF 1.1 Category or Subcategory, so organizations that assessed against 1.1 will not find a matching outcome to carry forward.

The risk is straightforward. If an attacker can forge an assertion, replay one captured earlier, or alter a valid one in transit, the relying application may grant access to an account that was never authenticated. The control is hard to run well because it crosses ownership lines. The identity provider team controls signing keys and assertion lifetimes, application teams control how they validate signatures, audience and expiry, and the team that manages certificates controls rotation and revocation. A gap in any one of these can defeat the others. The practical starting point is an inventory of every federated relationship, with the signing certificate, accepted algorithms, encryption requirements and assertion lifetime recorded for each.

NIST's CSF 2.0 Reference Tool maps PR.AA-04 to SP 800-53 Rev. 5.2.0 control IA-13 and to Annex A control 5.16 of ISO/IEC 27001:2022. These mappings are taken from NIST's and ISO's published references and should be checked against the current versions before they are cited in an assessment, since the referenced documents change. Treat the mappings as a pointer to where assessors will look, not as proof of compliance. Confirm with the assessor which mapping and evidence set they will use before you build the evidence package.

Which systems and parties fall under PR.AA-04 identity assertions protected

PR.AA-04 reaches every place where one system vouches for a person or service to another. The scope usually runs from the identity provider through the applications that accept its assertions, out to partners and SaaS vendors that trust them, and down to the keys and logs that make the trust verifiable. Confirm the boundary with your assessor before you decide what is in scope.

Identity providers that issue assertions

The identity provider authenticates users and produces the assertions or tokens that applications rely on. Decide whether one identity provider serves all applications or whether business units, environments or acquired companies run their own. Each separate provider adds its own configuration, signing keys, session settings and administrators to the assessment boundary. Ask which provider is authoritative for each population of users and whether any application can sign in without it.

Relying applications that consume assertions

Every application that accepts a single sign-on assertion is in scope for how it validates that assertion. Check whether each application verifies signatures, checks the issuer and audience, enforces expiry and rejects unsigned or unexpected assertions. Applications built in-house, packaged products and legacy systems often differ on these checks. Build an inventory that records the protocol, the trusted issuer and the validation method for each one.

Federation trust with partners and SaaS

Federation relationships with external parties extend your assertions beyond your own boundary. Determine which partners, customers or SaaS vendors hold trust in your identity provider, and which external identity providers you trust to assert identities into your systems. Each trust relationship needs documented metadata, certificate ownership, contacts for key rotation and a process to remove the trust when a relationship ends. Confirm with your assessor whether these parties fall inside your system boundary or only at its edge.

Service-to-service identity and tokens

Services that call other services often present tokens or certificates instead of user assertions. These credentials fall under PR.AA-04 when a receiving service relies on them to make an access decision. Decide which workloads issue or accept service identities, how long their tokens live and whether certificates are issued dynamically or by hand. Mutual TLS and workload certificates are common here, so include the issuing authority and its renewal process in scope.

Signing and encryption keys and certificates

The keys and certificates that sign or encrypt assertions are the root of their protection, so they belong in scope on their own terms. Identify where each private key is stored, who can use it, how it is rotated and what happens when it is compromised. Track certificate expiry dates for signing and encryption, and confirm that key material never leaves a controlled store. Ask your assessor how key custody is evidenced, since the answer shapes which administrators and systems are included.

Logs that prove validation happened

PR.AA-04 is demonstrated by evidence that assertions were checked, not only that the checks were configured. Logs of authentication events, assertion issuance, signature failures, rejected assertions and key changes need to be retained, protected from modification and reviewable. Include the log sources and the systems that store them within scope. Confirm with your assessor which log fields, retention period and review cadence they expect, since these are set by your own policy and the assessment approach.

How an assessor tests identity assertion protection

This table sets out, for each test an assessor is likely to run, how the test is performed, what evidence the assessor asks for, and where organizations usually fall short. Read it as a preparation checklist: the organization owns its federation configuration, while the independent assessor decides whether the evidence supports the outcome.

Test area	Test approach and evidence requested	Common findings
Signing configuration and key ownership	Interview the identity owner, review the identity provider's signing settings for each relying party, and confirm which key signs assertions and who controls it. Evidence: configuration exports, key inventory entries, and access records for the signing key.	Signing disabled or left at default for some applications, or the signing key held by a vendor or former administrator with no documented owner.
Rejection of unsigned or wrongly signed assertions	Run sampled test logins with a modified or unsigned assertion, or one signed by a non-trusted key, against each relying application. Evidence: test scripts or captured requests, the application's rejection responses, and related log entries.	Relying applications accept assertions without checking the signature, or validate only for the first application onboarded.
Encryption of sensitive assertion attributes	Confirm which assertions carry personal or privileged attributes, then review whether encryption is configured for those flows and whether the relying party can decrypt them. Evidence: data-flow notes, encryption settings, and a sampled decrypted test assertion.	Assertions with personal data or group membership sent unencrypted over channels that assume transport protection alone.
Certificate and key rotation	Review the rotation procedure, the schedule actually followed, and the expiry dates of signing and encryption certificates currently in use. Evidence: rotation records, change tickets, certificate inventory, and metadata showing the active key.	Certificates past their expiry date still trusted, or rotation done without updating every relying party's metadata, causing outages or silent fallbacks.
Audience, issuer and expiry checks	Send sampled assertions with a wrong audience, wrong issuer, or expired validity window to each relying application and observe the outcome. Evidence: test results per application and the configuration that defines the expected values.	Applications check the signature but not the audience or validity period, so an assertion issued for one service can be replayed at another.
Federation metadata change control	Trace a recent change to a trusted partner's metadata from request through approval to deployment. Evidence: change records, approvals, the metadata file history, and who can edit trust relationships.	Metadata updated directly in production with no approval record, or trust added for partners that no longer have a documented business need.
Logging of assertion validation failures	Review whether failed signature, audience and expiry checks generate logs that reach a monitored location, and sample alerts raised from them. Evidence: log configuration, sample events, and the alert rules or tickets they produced.	Validation failures logged locally by applications only, with no central collection or review, so attempted abuse goes unseen.
Interviews and ownership of the federation process	Ask who approves federation changes, who responds when a relying party reports an authentication fault, and how these roles are recorded. Evidence: role descriptions, runbooks, and the named owner for each relying party.	Owners cannot be named for some applications, or the people who know the configuration have left the team without handover.

How to implement PR.AA-04 identity assertion protection, step by step

This sequence moves an organization from an unknown set of single sign-on and federation links to a documented, tested state in which every identity assertion is signed, conveyed and checked the same way.

Inventory identity providers and relying applications
The identity team lists every identity provider, every application that accepts assertions from it, and the protocol each pair uses, such as OpenID Connect, SAML, or a Kerberos ticket path. The inventory also records the owner of each link, the environment it runs in, and whether a vendor or partner is on the other side. Done means the inventory is reviewed by the application owners, and any link that cannot be named has been either assigned an owner or scheduled for removal. Output: a federation inventory with one row per trust relationship.
Set signing and encryption standards
The security architecture team writes the approved standards for each protocol in use, including accepted signature algorithms, key lengths, whether assertions must be encrypted in addition to signed, and the maximum lifetime of an assertion. The standards should follow the current guidance of the relevant protocol specifications and the organization's own cryptography policy, which your team should confirm with the standards owners. Done means the standard is approved by the risk owner. Output: a signed-off assertion standard listing allowed and prohibited algorithms per protocol.
Assign key and certificate ownership and rotation
Each signing key, encryption key and metadata certificate gets a named owner, a storage location, and a rotation procedure that covers both scheduled replacement and emergency replacement after suspected compromise. Where certificates are issued automatically inside a platform, the team confirms who can approve issuance and who receives renewal failures. Done means a key register exists and a rotation runbook has been walked through once by the owners. Output: a key and certificate register with owner, expiry, and rotation steps for each entry.
Configure relying applications to validate assertions
Each relying application is configured to check the signature against the trusted identity provider key, the issuer, the intended audience, and the expiry and not-before times, and to reject assertions that fail any check. Platform engineers apply the settings through the same change process used for other production configuration, and the configuration is kept in version control where the application allows it. Done means each relying application has a recorded baseline that matches the standard from the earlier step. Output: a configuration baseline per application, with the validation settings listed.
Restrict and log federation metadata changes
Changes to federation metadata, trusted certificates, redirect targets and assertion attributes are limited to named administrators and routed through an approval step. Every change is written to a log that is retained and reviewed, so that an unexpected new trust or a changed signing key can be traced. The identity provider's audit output should be forwarded to the central logging system, which you should confirm with the platform team. Done means a test change produces a log entry that a reviewer can find. Output: an access list for metadata administrators and sample log records.
Test negative cases for assertions
The test team submits deliberately bad assertions to each relying application, including a tampered attribute, a wrong signature, an unknown issuer, a wrong audience, an expired assertion, and a replayed assertion where the protocol supports replay detection. Each application must reject every case and record a clear error. Tests are repeated after any configuration or key change. Done means every negative case has a recorded expected result and an observed result that matches. Output: a test record per application with inputs, expected outcomes and observed outcomes.
Record decisions and schedule reviews
The team writes down the decisions made in the earlier steps, including the approved standards, accepted exceptions, owners, and the reasons for any relying application that cannot meet the standard. The record names who reviews it and at what interval, and links to the inventory, key register, baselines and test records so an assessor can follow the trail. Done means the record is approved by the risk owner and the review date is in the governance calendar. Output: a decision log and a review schedule for PR.AA-04 evidence. An independent assessor will test whether this record is accurate, so the organization should not treat it as a formality.

Evidence that satisfies PR.AA-04 identity assertions protected

PR.AA-04 is tested by looking at how identity assertions are generated, protected and checked across single sign-on and federation. The cards below are the artifacts an assessor will ask to see, each with a suggested refresh routine and sign-off owner. The organization owns these records, and the independent assessor decides whether they are sufficient.

Identity provider and relying party inventory

A current list of every identity provider and every application that relies on it, with the protocol used for each link, such as OAuth2 and OpenID Connect, SAML, LDAP or proxy-based sign-in. Assessors use it to confirm that no federation path exists outside the documented set. Refresh it from the identity platform's own configuration export on a fixed schedule, and have the identity service owner sign off each quarter, noting any relying party added or retired.

Assertion signing and encryption standard

A written standard that names the approved signing and encryption algorithms, minimum key sizes, and the protocol profiles permitted for each relying party. It is the yardstick the assessor uses to judge the exported settings below. Confirm the approved list against current guidance from your own cryptography authority, record the review date, and have the CISO or security architecture lead approve each revision.

Exported signature and encryption settings

Configuration exports from each identity provider and service provider showing whether assertions are signed, whether encryption is required, which algorithms are active, and whether unsigned or weakly signed responses are rejected. This is the most direct evidence that the standard is implemented rather than documented. Schedule the export after every change window and retain the files with timestamps. The platform owner signs each export and the security engineer countersigns the comparison against the standard.

Certificate and key lifecycle records

Issuance, renewal, rotation and revocation records for the signing and encryption keys and certificates used in assertions. Show who requested each certificate, how the key was generated, where it is stored, and when it expires. Automated issuers such as the OpenBao PKI secrets engine or cert-manager produce these logs natively, so confirm they are exported to the evidence store. The PKI or key custodian owns the record, and the security operations lead reviews expiry dates monthly.

Negative test results for rejected assertions

Test records that show the system refuses tampered, expired, unsigned, wrongly signed, replayed or wrongly addressed assertions. Positive login tests alone do not show that validation works. Keep the test scripts under version control, run them after each identity configuration change, and file the results with the release record. The application security team signs off the test set, and the independent assessor decides whether coverage is adequate.

Federation metadata change logs

A dated log of every change to federation metadata, including new signing certificates, endpoint URLs, accepted algorithms and trust relationships with partners. Each entry should record the requester, the approver and the reason, and link to the change ticket. Reviewing this log against the inventory exposes changes that bypassed approval. The identity service owner reviews the log monthly and the change advisory board signs off on any metadata change that alters trust.

Which open-source tools can produce PR.AA-04 evidence

authentik is an identity provider released under the MIT license. For PR.AA-04, its relevance is that it issues the identity assertions that applications rely on, so applications can delegate sign-in to one place instead of each maintaining its own login logic. Its documented provider types include OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Each provider type produces a different kind of assertion or session, so the evidence differs by protocol.

Protocol inventory: Export the list of configured providers and the applications bound to each, so you can show which assertion protocol protects which application.
Signing configuration: Record which signing keys and certificates the OAuth2, OpenID Connect and SAML providers use, and who can change them.
Application registration: Keep the records that show each relying application was registered with the expected redirect URIs and assertion consumer endpoints.
Audit logs: Retain authentication and configuration change logs so you can show when assertion settings were altered and by whom.
Proxy and session settings: Document how proxy providers handle session cookies and token lifetimes for applications that do not speak a federation protocol.

Before relying on any of these, confirm the current provider types, signing options and log export features against the release you deploy, because capabilities change between versions.

What meeting PR.AA-04 identity assertion protection costs

This table breaks the cost of protecting SSO and federation assertions into components, showing who is paid, whether each recurs, what drives it and how to contain it. Read it as a checklist for a written quote, since no price or duration is implied. The main takeaway is that self-hosted open-source components can remove license spend, but engineering and evidence effort stay with the organization or its partner.

Cost component	One-time or recurring	What drives it	How to keep it down
Licenses for commercial identity or key management products	Recurring (usually annual or per user or per node)	Number of users, relying applications, certificates and key operations the product must cover	Confirm whether self-hosted open-source options such as authentik, FreeIPA or OpenBao meet the required assertion and key features, and price any commercial add-ons separately
Engineering time to configure relying applications	One-time per application, plus changes when apps are added	Number and diversity of relying applications, protocols (OIDC, SAML, LDAP, Kerberos), and custom claim mappings	Ask for an itemized scope per relying application and reuse a standard configuration pattern across similar apps
Key and certificate lifecycle operations	Recurring	Number of signing keys and certificates, rotation frequency, and whether issuance is automated (for example cert-manager or the OpenBao PKI engine)	Automate issuance and renewal, document rotation procedures once, and agree in the quote who performs rotations and emergency revocations
Evidence upkeep	Recurring	Frequency of assessments, number of configuration baselines, and how much evidence must be collected by hand	Export configuration and key inventory records on a schedule, and define in the quote which evidence artifacts are delivered and how often
External security testing or configuration review	Recurring or per engagement	Scope of assertion handling tested (signature validation, replay, token lifetime, redirect handling) and number of relying applications in scope	Fix the test scope in writing, test representative applications first, and require a deliverable list with retest terms
Auditor sampling	Recurring, per assessment cycle	Number of relying applications and key or certificate records the independent assessor selects, and how clearly evidence is organized	Keep a single register of identity providers, relying parties and signing keys so samples can be pulled quickly, and confirm with the assessor which samples they will request

Where organizations fall short on identity assertion protection

PR.AA-04 asks whether identity assertions are protected, conveyed and verified wherever single sign-on and federation carry them. The gaps below tend to appear in the same places: the relying application, the signing key, the federation metadata, the assertion content, the test suite and the inventory of connected applications. Each card names the fix and the evidence an assessor would expect to see.

Relying applications accept unsigned assertions

A service provider that skips signature validation will trust any assertion that reaches it, including one an attacker has forged or altered. Check every SAML and OpenID Connect client configuration and confirm that the application validates the signature against the identity provider's published key before it creates a session. The fix is a configuration baseline for each application type, with signature validation switched on and tested. Evidence is the saved configuration of each relying party, plus a test run showing that a tampered assertion is rejected.

No owner for signing keys

Assertions are only as protected as the key that signs them. When no named role owns the signing key, nobody schedules its rotation, tracks its expiry or confirms that old keys were retired. The fix is a written key custody record that names an owner, a storage location, a rotation trigger and a retirement procedure. Certificates used for signing can be issued and renewed through a managed PKI, such as the OpenBao PKI secrets engine, so renewal does not depend on someone remembering a date. Evidence is the custody record, the rotation log and the issuance history.

Federation metadata changed without review

Federation metadata defines which signing certificates, endpoints and assertion formats a partner is trusted to use. A change pushed without review can silently add a rogue certificate or redirect assertions to another endpoint. Treat metadata as a controlled configuration item: require a second person to approve each change, compare the new file with the previous version, and record the source of the update. Evidence is the change ticket for each metadata update, the diff that was reviewed and the approval record.

Assertions with personal data sent unencrypted

Some assertions carry attributes such as names, email addresses, department or role codes. If the identity provider signs but does not encrypt these assertions, personal data travels in a form that anyone with access to the message path can read. Confirm which attributes each relying party receives, remove any that the application does not need, and enable assertion encryption for attributes that remain sensitive. Evidence is the attribute release list for each application, the encryption settings and a sample assertion showing what is exposed.

No negative testing of audience and expiry

Positive tests show that a valid login works. They do not show that the application refuses an assertion issued for a different audience, one that has expired, or one with a replayed message identifier. Build negative test cases for each relying party: an assertion addressed to another service, an assertion past its validity window and a reused assertion. Run them after every configuration change and keep the results. Evidence is the test plan, the recorded results of each negative case and the retest after any fix.

Inventory omits business-added SaaS applications

Business teams often connect software-as-a-service tools to single sign-on directly, without a ticket to the identity team. Those connections fall outside the certificate inventory, the metadata review and the negative tests, so their assertions are never checked. Reconcile the identity provider's application list against procurement records and the asset inventory at a set interval, and require every new connection to be registered before go-live. Evidence is the reconciled inventory, the exceptions list with owners and the dates each gap was closed.

Who does what for PR.AA-04: your team, a partner and the auditor

Your organization owns PR.AA-04. Accountability for how identity assertions are protected, conveyed and verified stays with the people who run the identity provider, the applications that trust it and the risk owners who accept residual risk. Nobody outside the organization can make those decisions on its behalf, and an assessor will look for named owners and dated approvals.

Owning the controls: Name an accountable owner for the identity provider, the federation trust relationships and the certificate and key lifecycle behind them.
Approving the signing standard: Decide which assertion format, signature algorithms, encryption settings and certificate lifetimes are acceptable, and record the decision in a policy or standard.
Signing off evidence: Review configuration exports, test records and change tickets before they are filed, and confirm they match what is running in production.
Managing exceptions: Document any application that cannot meet the approved standard, with a compensating control, an owner and a review date.
Maintaining the inventory: Keep the list of trusted service providers, relying applications and signing keys current as systems are added or retired.

Before engaging anyone, confirm that these owners exist by name and that they have the authority to approve changes to federation settings.

Questions buyers ask about PR.AA-04 identity assertion protection

What does protecting identity assertions cost in effort?

Effort depends mostly on how many applications rely on single sign-on or federation, how many of them already use standards-based signing and encryption, and how much of the setup is new. Work usually splits into a review of current sign-on flows, configuration of signing, encryption and signature validation in the identity provider and each relying application, testing of failure paths, and documentation for the assessor. Costs are one-time for the initial build and recurring for certificate renewal, key rotation, upgrades and periodic reviews. No supplied figure sets a price, so ask any partner for a quote built from a written scope that lists each application and each identity provider involved.

How long does identity assertion protection take to implement?

The timeline is set by the number of federated applications, the state of their current configuration, how many teams must test changes, and whether signing keys and certificates are already managed centrally. Organizations with one identity provider and a small set of applications generally need less time than those with legacy applications that require custom assertion handling. No duration has been supplied for this work, so ask for a timeline tied to a written scope and confirm change windows with application owners before work starts.

What does the organization need to provide for this work?

The organization must provide administrative access to the identity provider, a list of relying applications with their owners, and decisions on key ownership, certificate authorities, key lengths and rotation intervals. It also needs a named owner for each federated application who can approve changes and test sign-in after them. Change control, a test environment that mirrors production sign-in, and log access for verifying assertion validation are also required. Agree these responsibilities in the scope document so that delays in access or decisions do not become unplanned schedule risk.

Can an internal team protect identity assertions without outside help?

A team that already operates its identity provider, understands SAML and OpenID Connect signing and encryption, and can test relying applications can usually do this work alone. Teams with limited federation experience, many legacy applications or no test environment often benefit from an implementation partner for configuration and evidence preparation. Whatever the choice, the organization owns the control and its outcome. DeployOpen prepares systems, configuration and evidence under a fixed-scope written agreement, but it does not issue audit reports or certifications.

Does NIST certify alignment with the CSF 2.0 Subcategories?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans to develop a conformity assessment program. Alignment with PR.AA-04 is shown through the organization's own documented assessment, supported by evidence such as configuration records, test results and key management logs. Any firm that claims to certify CSF alignment is making a claim NIST does not support, so ask what independent assessment is offered and who would issue any report.

How does PR.AA-04 relate to ISO/IEC 27001:2022 control 5.16 and SP 800-53 IA-13?

The NIST CSF 2.0 Reference Tool maps PR.AA-04 to ISO/IEC 27001:2022 Annex A control 5.16 and to SP 800-53 Rev. 5.2.0 control IA-13 as informative references. Those mappings show where the same concern appears in other frameworks, but they are not equivalence claims, and an assessor will still test each framework's own requirements. Use the mappings to reuse evidence, such as signing configuration and validation test results, while checking that each framework's wording and scope are met. Confirm the mapping version in the Reference Tool before relying on it in an audit.

Which open-source tools support identity assertion protection?

Several self-hosted projects handle parts of this work. authentik (MIT) acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. For certificates used in assertions and transport, OpenBao (MPL-2.0) issues dynamic X.509 certificates through its PKI secrets engine, and cert-manager (Apache-2.0) manages TLS certificates for Kubernetes or OpenShift workloads. Confirm each tool supports the signing and encryption options your applications require before choosing it.

How DeployOpen scopes and prepares PR.AA-04 identity assertion evidence

DeployOpen approaches PR.AA-04 by first agreeing in writing which single sign-on and federation paths, identity providers and relying applications are in scope. We then prepare the self-hosted platforms, configuration and evidence that show identity assertions are protected, conveyed and verified, while the organization keeps ownership of its controls.

How we scope

Engagements are fixed-scope, with the list of identity providers, relying applications and federation partners agreed in writing first.
We record which assertion protocols, signing keys and encryption settings each in-scope application depends on.
Ongoing support and continuous testing of assertion handling are available as a retainer after the initial scope closes.

How we build

We deploy and harden self-hosted identity providers inside your own cloud accounts, data centers or air-gapped networks.
We configure OAuth2, OpenID Connect and SAML providers so signed and encrypted assertions meet the standards-based practices you agree on.
We test signature validation and rejection of tampered or expired assertions, then record the results for review.

How we hand over

You receive configuration records, key ownership and rotation procedures, and a map from each assertion flow to the PR.AA-04 Implementation Examples in scope.
Test results and evidence samples are packaged so your internal team or an independent assessor can trace each claim.
Handover includes documented runbooks, so your staff can operate and audit assertion settings after the engagement ends.

How we support

Support covers certificate and signing key renewal, provider upgrades and changes to relying applications.
Periodic re-testing confirms that assertion signing, encryption and validation still behave as documented after changes.
Your organization remains responsible for the control itself, and an independent auditor or certification body issues any formal report.