Employees federated through IAM Identity Center suddenly cannot access AWS accounts via permission sets, while direct IAM users still work. Helpdesk reports No access errors after IdP certificate renewal. Failed sign-ins started within the hour. Which troubleshooting path isolates the authentication failure fastest?

The failure pattern isolates authentication at the external IdP trust because only federated Identity Center users fail while direct IAM users succeed, and onset correlates within the hour of IdP certificate renewal, so checking CloudTrail sign-in events for SAML errors like InvalidSignature or ExpiredCertificate together with Identity Center IdP trust metadata to confirm the renewed certificate, validity dates, thumbprint and issuer were imported is the fastest path. Reviewing permission set assignments and re-provisioning accounts is standard for authorization when users authenticate but lack account access, yet here sign-in itself fails before permission evaluation, so it corrects the wrong layer. Inspecting SAML attribute mappings and group claims is valid for wrong-role or missing-group symptoms after successful authentication, but mismapped claims do not produce sudden global failure tied to renewal and leave an invalid signature unchecked. Examining SSO events and refreshing STS tokens addresses session continuity after authentication, yet temporary credentials depend on a valid SAML assertion first and direct IAM success proves STS and IAM are healthy, so it treats a symptom downstream of the broken trust. Exam caveat: do not confuse Identity Center federation with IAM SAML roles or AD trusts; permission sets authorize after IdP authentication, so always validate IdP metadata first when all federated logins break together. Practical check: in Identity Center download current IdP metadata, compare certificate expiry and fingerprint to the IdP admin console, re-import if mismatched, then test with a single user and confirm CloudTrail shows successful federated sign-in.