Cognito ACR/AMR: `AcrConfiguration` accepted but never returned, tokens have no `acr`/`amr`

What’s been published

The SDK model update is real. The October 2, 2026 SDK release notes say Cognito user pools now support the OIDC-standard ACR and AMR claims on access and ID tokens, plus step-up authentication through the existing authentication APIs. The developer guide’s pre-token-generation claims table also already lists acr and amr on both ID and access tokens as claims you can’t add, modify, or suppress. That table doesn’t tell you whether the backend is issuing them yet.

What your symptoms point to

Your symptoms fit the backend not yet recognizing the feature for your pools. They don’t fit a misconfiguration on your side.

When a field in a write request is accepted without error but never comes back in Create or Describe responses, the service is usually dropping a parameter it doesn’t know about yet. SDK models sometimes ship ahead of, or alongside, a staged service rollout.
urn:bogus:nope not raising an error is the strongest clue. If TARGET_ACR_VALUES were being evaluated, validation would fire. It’s being ignored, not rejected.
Managed login behaving the same way rules out anything specific to InitiateAuth.

Two things to check before concluding it’s a rollout gap

Feature plan. All your tests are on Essentials pools. Several of Cognito’s newer security features are Plus-only, and step-up authentication fits that pattern. Create a throwaway Plus pool in one region and repeat the CreateUserPool and DescribeUserPool round trip. If AcrConfiguration is returned there, it’s a tier restriction, and the API should arguably be rejecting the field on Essentials rather than silently accepting it.
Region list. Check whether the launch documentation, once published, limits the feature to specific regions. That said, seven regions all behaving the same makes a regional gap unlikely.

On account-level enablement

I’ve found nothing indicating an opt-in or allow-list. Cognito features are normally controlled by feature plan, not per-account flags. A staged deployment can still reach accounts at different times, though.

If a Plus pool behaves the same way, open a support case with request IDs for one CreateUserPool call and one InitiateAuth call, including the bogus-value test. Ask whether the feature is fully deployed and whether it requires the Plus plan. The silent acceptance of an invalid TARGET_ACR_VALUES is worth reporting either way, since it contradicts the documented behavior.