signup-signin-with-phone-number: align sample countryList default with Learn mitigation guidance

[gfortaine]

Summary

Aligns the signup-signin-with-phone-number custom policy sample with the existing Microsoft Learn mitigation guidance for SMS toll fraud (IRSF), by shipping a restrictive-by-default countryList in the sample itself and cross-linking phone-based-mfa.md.

The sample now ships a Nordic-only allow-list (NO, SE, DK, FI, IS, FO, AX) on all three locale paths (en / nb / sv). The previous world-wide list is preserved as XML comments, split into two tiers (HIGH-RISK IRSF hotspots / Lower-risk OECD/EU) so consumers widen the allow-list by uncommenting the tier they accept.

Tenants outside the listed countries must edit countryList before first deployment — this is called out at the top of the sample README and inline in the XML.

Problem

Two Microsoft artifacts cover phone-based authentication on Azure AD B2C and complement each other:

• The sample policies/signup-signin-with-phone-number/ — one of the phone-based auth samples developers reach when implementing phone-based authentication.
• The mitigation guide phone-based-mfa.md on Microsoft Learn — contains the existing mitigation guidance (countryList, CAPTCHA, Conditional Access, Azure Monitor workbook) against fraudulent phone-based MFA sign-ups.

There was no in-repo reference from the sample to the guide, and the sample shipped with no allow-list at all — so a developer uploading the policy as-is was open to IRSF by default. This PR aligns the sample's out-of-box behavior with the Learn guidance, preserves the world list as commented tiers for opt-in widening, and cross-links the guide from the sample README.

Changes

#	File	Change
1	policies/signup-signin-with-phone-number/policy/TrustFrameworkLocalization.xml	Sample default configuration change. countryList LocalizedString in both api.phonefactor.sv and api.phonefactor.nb restricted to Nordic ISO 3166-1 alpha-2 codes (NO, SE, DK, FI, IS, FO, AX). Original world list preserved as XML comments, split into two risk tiers: HIGH-RISK (IRSF / SMS-pumping hotspots — must not be re-enabled without complementary controls: CAPTCHA, Conditional Access, Azure Monitor anomaly alerts, per-tenant SMS spending cap) and Lower-risk (OECD / EU / major commercial markets, still to be reviewed before enabling). Consumers opt into a wider list by uncommenting the tier they accept.
2	policies/signup-signin-with-phone-number/policy/phone-signup-signin.xml	Wires the allow-list on the default English UX path: new BuildingBlocks > Localization block with the same Nordic countryList (NO, SE, DK, FI, IS, FO, AX), and an RP-level api.phonefactor ContentDefinition override (LocalizedResourcesReferences MergeBehavior="Prepend") so api.phonefactor.en is actually applied on the phone-entry page.
3	policies/signup-signin-with-phone-number/README.md	Security section at the top: link to phone-based-mfa.md, documents the Nordic default shipped in the XML, points at the two modified files, and documents the action required before production (extending the allow-list with ISO 3166-1 alpha-2 codes of the countries where users actually are).
4	readme.md	Security notice above the samples table, and a mitigation note on the existing phone-based sample row.

Sources

Recommendation	Source
Restrict countryList to an allow-list	phone-based-mfa.md § custom policy and § user flow
Add CAPTCHA to sign-up and sign-in	add-captcha.md
Apply Conditional Access by location (sign-in flows; does not cover sign-up — per Learn)	conditional-access-user-flow.md
Monitor phone-authentication failures via Azure Monitor workbook	phone-based-mfa.md § Create a phone-based MFA events workbook
Neutral definition of the attack vector (term not currently used on learn.microsoft.com)	Wikipedia — International Revenue Share Fraud

[gfortaine]

hi @JasSuri, @yoelhor — quick re-frame now that the pr has narrowed.

this is now scoped to one existing sample: 4 files, ~208 lines, no new sample, no cross-repo security proposal. just signup-signin-with-phone-number.

what actually ships:

• policy/TrustFrameworkLocalization.xml — countryList in api.phonefactor.sv / api.phonefactor.nb set to a nordic default (NO, SE, DK, FI, IS, FO, AX). the previous world list is preserved as xml comments, split into two tiers (high-risk irsf hotspots / lower-risk oecd-eu), so a consumer widens the allow-list by uncommenting the tier they accept.
• policy/phone-signup-signin.xml — adds an RP-level api.phonefactor override (LocalizedResourcesReferences MergeBehavior="Prepend") so api.phonefactor.en applies on the default phone-entry page, carrying the same nordic countryList.
• README.md + root readme.md — link out to phone-based-mfa.md and document the nordic default + the opt-in path to widen it.

tradeoff worth stating plainly: a tenant outside NO, SE, DK, FI, IS, FO, AX who uploads this sample as-is will need to edit countryList before their users can sign up. that's called out at the top of the sample readme and inline in the xml, but it is a behavior change for anyone currently uploading the sample as-is.

two narrow questions, one each:

• @JasSuri — is there any scope blocker to keeping the current sample-default xml change? if yes, is the blocker specifically that samples shouldn't change runtime defaults out-of-box?
• @yoelhor — is the way phone-based-mfa.md is referenced from the sample's readme consistent with how you'd want that guide cited from a sample?

a one-line reply is enough on either side — "sample-default ok" / "readme-only" / "citation ok" / "please change citation". happy to rework on any of those.

thanks.

[dogoku]

@gfortaine just a question. You mention that these are blocked at the "UX layer".
Does that mean that this would not prevent someone that is replicating the form submission programmatically?
(I.e they replicate the request the form makes, using curl)