Microsoft Entra client secrets

• Provider documentation Graph PowerShell Add-MgApplicationPassword SecretText examples (3 + 8Q~ + 34) · observed 2026-09-23 · Microsoft Graph PowerShell's Add-MgApplicationPassword reference (learn.microsoft.com) prints two example SecretText values, each 3 characters (equal to the printed 3-character Hint), the digit 8, the literal Q~, and 34 characters, 40 in total. The Q~ marker at offset 4 and the 8-variant's 40-character width come from these examples, not from a stated grammar. The 7Q~ 37-character previous format, the digit-to-length coupling and the body alphabet are corroborated only by Microsoft's security-utilities code (SEC101/156) and third-party tools
• trufflehog 3.97.4
• gitleaks 8.30.1
• Twin source Purview Entra client secret definition · observed 2026-09-22 · learn.microsoft.com states the client secret is "a combination of up to 40 characters" of letters, digits, "-", "_", "." and "~". It backs a length twin (41 characters) only; the digit+Q~ marker is example- and tool-corroborated (redact-secret#655) and the positive tier is unchanged

Re-tiered 2026-09-23 (#112, provider evidence redact-secret#655). T1 rests on a provider-domain SDK-reference example, not a prose grammar: no Microsoft page states the format in prose, and a Graph SDK maintainer calls the two values "examples in the documentation", not issued secrets. Accepting an SDK-reference example as the T1 source is a maintainer ruling, on the same footing as the google-api-key example precedent (and terraform-cloud-token/supabase-management-token before it), not a change to the T1 bar. Retained limitations the provider examples do not settle: the pattern accepts any marker digit where the provider shows only 8 (and Microsoft code only 7|8); it accepts 37-40 characters with any digit where SEC101/156 couples 7Q~ to exactly 37 and 8Q~ to exactly 40; and other Microsoft pages disagree without describing the Q~ format (Graph passwordCredential/addPassword say "16-64 characters" with a legacy 32-character markerless example, Purview says "up to 40" with no Q~). redact-secret-benchmarks#161 (following redact-secret#655's web-search pass) found the 3-character lead excluded "-", a false negative: portal- and CLI-issued secrets starting with "-" are real (four independent reports, one measured at 8Q~/40, including one that breaks `az login -p`), TruffleHog 3.97.4's azure_entra/serviceprincipal/v2 detector (merged 2024-11-20; the earlier review only checked v1, which has no Q~ marker) already accepts "-" in the lead, and Microsoft's own scanner rule (microsoft/security-utilities SEC101/156 — provider code, not documentation) agrees. Widened to match; gitleaks's azure-ad-client-secret rule still excludes "-", so it stays cited for the marker only. Product main detects the leading-dash shape since redact-secret#707 (fix dc855b6; known gap product-707 fixed); the published 0.1.0-beta.6 package still misses it. The marker-digit and length-coupling points stay open as separate precision issues under #161, not fixed here.