# Make federation trust explicit before accepting another identity provider's assertion > Federation moves authentication information between separately administered parties. Document which provider, assertion, attributes, audience, assurance, and failure paths each relying service will accept. - Canonical URL: https://update.dsesecurity.com/updates/federation-trust-assertion-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:13+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Federation moves authentication information between separately administered parties. Document which provider, assertion, attributes, audience, assurance, and failure paths each relying service will accept. ## Potentially affected Organizations using workforce, customer, partner, or multi-tenant identity federation between independently administered identity providers and relying applications. ## DSE recommendation Create an approved federation register, constrain every assertion to its intended relying party and purpose, minimize released attributes, and test revocation and provider failure before production reliance. ## Article Bottom line: federation is a trust relationship, not merely a sign-in convenience. Before an application accepts an external identity assertion, the organization should be able to name the credential service provider, relying party, permitted attributes, intended audience, assurance expectations, validation rules, and the process for ending that trust. ## Source fact: what NIST covers [NIST SP 800-63C-4](https://csrc.nist.gov/pubs/sp/800/63/c/4/final) focuses on identity federation and the assertions used to implement it. NIST describes federation as allowing a credential service provider to provide authentication attributes and, optionally, subscriber attributes to separately administered relying parties. A relying party may also use more than one provider. The July 2025 publication supersedes the earlier SP 800-63C. That scope matters operationally. The source is about how parties exchange and rely on identity information; it is not evidence that any particular federation is correctly configured, that an upstream account remains trustworthy, or that an asserted attribute should authorize a sensitive business action. ## What the source does not establish The NIST guideline does not certify a particular identity platform, tenant, application, or implementation. It does not prove that a partner’s enrollment process matches yours, that every attribute is current, or that a relying application validates the intended recipient and context. It also does not make federation a substitute for application authorization. Applicability depends on the chosen federation pattern, assurance needs, contracts, privacy obligations, attribute sources, protocol implementation, key handling, session behavior, and the consequences of an incorrect assertion. ## Applicability questions - Which separately administered parties issue and consume each assertion? - What audience, purpose, subject, and assurance information must the relying party validate? - Which attributes are necessary, who is authoritative for them, and how quickly can they be corrected or revoked? - What happens to active sessions when the upstream account, signing key, federation agreement, or provider becomes unavailable? - Which decisions remain inside the application after authentication succeeds? ## DSE recommendation: govern the trust relationship The following steps are DSE recommendations based on the cited source. - Maintain a federation register with the business owner, technical owner, provider, relying party, protocol, environments, approved claims, key or metadata locations, assurance expectation, and review date. - Configure the narrowest practical audience and redirect boundaries. Reject assertions that are expired, improperly signed, intended for another recipient, or missing required context. - Release and retain only necessary attributes. Record the authoritative system and correction path for every claim used in access decisions. - Keep authentication and authorization distinct. After accepting an identity, evaluate current application permissions, resource policy, transaction context, and risk. - Test termination. Disable a test user, remove an entitlement, rotate federation keys or metadata, and confirm the relying application stops granting access within the documented window. - Prepare for provider or metadata failure without silently bypassing verification. Assign an owner and expiration to any emergency exception. ## Verification and evidence Retain the approved trust record, exported configuration, assertion-validation test results, sample redacted claims, key-rotation evidence, access and error logs, revocation timing results, and application authorization tests. Evidence should show both successful federation and safe rejection of invalid, stale, misdirected, or over-privileged assertions. ## Official references - [NIST SP 800-63C-4 — Digital Identity Guidelines: Federation and Assertions](https://csrc.nist.gov/pubs/sp/800/63/c/4/final) — National Institute of Standards and Technology; finalized July 31, 2025 - [NIST Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) — National Institute of Standards and Technology; living online edition ## Primary reference - Name: NIST SP 800-63C-4 — Digital Identity Guidelines: Federation and Assertions - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/63/c/4/final - Source publication date: 2025-07-31 ## Citation and use Preferred citation: “Make federation trust explicit before accepting another identity provider's assertion,” DSE Security, https://update.dsesecurity.com/updates/federation-trust-assertion-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.