{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/modern-password-policy-account-recovery/", "item": { "id": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "slug": "modern-password-policy-account-recovery", "url": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery.md", "json": "https://update.dsesecurity.com/api/v1/posts/modern-password-policy-account-recovery/" }, "title": "Modern password policy: strengthen sign-in without weakening account recovery", "summary": "Modern password policy emphasizes length, compromised-password screening, rate limiting, password-manager compatibility, and evidence-based changes while treating account recovery as a separate high-risk control.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-28T14:22:00+00:00", "modified_at": "2026-07-28T14:22:00+00:00", "reviewed_on": "2026-07-28", "reading_minutes": 3, "word_count": 471, "potentially_affected": "Identity providers, business applications, remote-access services, local accounts, password managers, help-desk reset processes, recovery contacts, privileged users, and legacy systems with limited password support.", "dse_recommendation": "Inventory password and recovery behavior, remove counterproductive rules where supported, block known-compromised choices, permit password managers, strengthen recovery verification, and test lost-authenticator scenarios.", "primary_source": { "name": "NIST SP 800-63B-4: Authentication and Authenticator Management", "url": "https://csrc.nist.gov/pubs/sp/800/63/b/4/final", "published_on": "2025-07-31", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: current password guidance has changed

\n

NIST SP 800-63B-4 says a password used as the only authentication factor must contain at least 15 characters. A password used only within multifactor authentication may be at least eight characters, and verifiers should permit at least 64 characters. NIST says verifiers should not impose composition rules, such as requiring mixtures of character types, and should not require periodic password changes unless there is evidence that an authenticator has been compromised. These requirements are written for federal digital identity systems; other organizations can use them as an evidence-based design reference while still checking applicable contracts, regulations, and product limits.

\n

NIST requires prospective passwords to be compared with a blocklist containing commonly used, expected, or compromised values. It also calls for rate limiting of failed attempts and permits password managers, autofill, and paste. The complete requirements and implementation notes are in NIST SP 800-63B-4. The guidance does not mean that a long password alone is phishing-resistant or that every legacy system can safely accept a policy change without testing.

\n\n

Treat recovery as another authentication path

\n

A strong primary authenticator can be undermined by weak recovery. NIST describes recovery methods with different assurance properties and requires notification when account recovery occurs. Knowledge-based questions are not an acceptable authentication factor because answers can often be discovered, guessed, or reused. Help-desk staff should not approve a reset merely because a caller knows information available in company directories, prior email, or public records.

\n

Document the recovery paths for a forgotten password, lost authenticator, replaced phone, departed administrator, unavailable identity provider, and suspected compromise. Identify which records establish identity, who may approve an exception, how the event is logged, and which independent channel receives notification. Recovery codes and spare authenticators need controlled issuance, storage, use, and revocation.

\n\n

DSE recommendation: migrate policy by system

\n
    \n
  1. Inventory identity stores and applications, including maximum length, unsupported characters, silent truncation, lockout behavior, password-history rules, and synchronization dependencies.
    2. \n
  2. For compatible systems, favor length and blocklist screening over predictable composition and routine expiration rules. Allow password-manager generation, paste, and autofill.
    3. \n
  3. Apply rate limits and monitoring that slow automated guessing without enabling easy denial of service. Protect reset endpoints as carefully as sign-in.
    4. \n
  4. Require a password change after credible compromise, exposure in a validated breach source, or an administrator-directed recovery—not merely because a calendar interval elapsed.
    5. \n
  5. Separate help-desk verification from approval for privileged or high-impact recovery. Notify the account owner through an independent registered channel and retain the event record.
    6. \n
  6. Test password changes, synchronization, service accounts, emergency access, lost-device recovery, and rollback in a pilot group before broad enforcement.
    7. \n
\n

Measure compromised-password blocks, recovery attempts, exception use, lockouts, failed synchronization, and confirmed takeover. Preserve stricter rules where a governing authority requires them, and record systems that cannot yet support the target policy with an owner and remediation plan.

", "content_text": "Source fact: current password guidance has changed\nNIST SP 800-63B-4 says a password used as the only authentication factor must contain at least 15 characters. A password used only within multifactor authentication may be at least eight characters, and verifiers should permit at least 64 characters. NIST says verifiers should not impose composition rules, such as requiring mixtures of character types, and should not require periodic password changes unless there is evidence that an authenticator has been compromised. These requirements are written for federal digital identity systems; other organizations can use them as an evidence-based design reference while still checking applicable contracts, regulations, and product limits.\nNIST requires prospective passwords to be compared with a blocklist containing commonly used, expected, or compromised values. It also calls for rate limiting of failed attempts and permits password managers, autofill, and paste. The complete requirements and implementation notes are in NIST SP 800-63B-4. The guidance does not mean that a long password alone is phishing-resistant or that every legacy system can safely accept a policy change without testing.\n\nTreat recovery as another authentication path\nA strong primary authenticator can be undermined by weak recovery. NIST describes recovery methods with different assurance properties and requires notification when account recovery occurs. Knowledge-based questions are not an acceptable authentication factor because answers can often be discovered, guessed, or reused. Help-desk staff should not approve a reset merely because a caller knows information available in company directories, prior email, or public records.\nDocument the recovery paths for a forgotten password, lost authenticator, replaced phone, departed administrator, unavailable identity provider, and suspected compromise. Identify which records establish identity, who may approve an exception, how the event is logged, and which independent channel receives notification. Recovery codes and spare authenticators need controlled issuance, storage, use, and revocation.\n\nDSE recommendation: migrate policy by system\n\nInventory identity stores and applications, including maximum length, unsupported characters, silent truncation, lockout behavior, password-history rules, and synchronization dependencies.\nFor compatible systems, favor length and blocklist screening over predictable composition and routine expiration rules. Allow password-manager generation, paste, and autofill.\nApply rate limits and monitoring that slow automated guessing without enabling easy denial of service. Protect reset endpoints as carefully as sign-in.\nRequire a password change after credible compromise, exposure in a validated breach source, or an administrator-directed recovery—not merely because a calendar interval elapsed.\nSeparate help-desk verification from approval for privileged or high-impact recovery. Notify the account owner through an independent registered channel and retain the event record.\nTest password changes, synchronization, service accounts, emergency access, lost-device recovery, and rollback in a pilot group before broad enforcement.\n\nMeasure compromised-password blocks, recovery attempts, exception use, lockouts, failed synchronization, and confirmed takeover. Preserve stricter rules where a governing authority requires them, and record systems that cannot yet support the target policy with an owner and remediation plan.", "content_markdown": "## Source fact: current password guidance has changed\n\nNIST SP 800-63B-4 says a password used as the only authentication factor must contain at least 15 characters. A password used only within multifactor authentication may be at least eight characters, and verifiers should permit at least 64 characters. NIST says verifiers should not impose composition rules, such as requiring mixtures of character types, and should not require periodic password changes unless there is evidence that an authenticator has been compromised. These requirements are written for federal digital identity systems; other organizations can use them as an evidence-based design reference while still checking applicable contracts, regulations, and product limits.\n\nNIST requires prospective passwords to be compared with a blocklist containing commonly used, expected, or compromised values. It also calls for rate limiting of failed attempts and permits password managers, autofill, and paste. The complete requirements and implementation notes are in [NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final). The guidance does not mean that a long password alone is phishing-resistant or that every legacy system can safely accept a policy change without testing.\n\n## Treat recovery as another authentication path\n\nA strong primary authenticator can be undermined by weak recovery. NIST describes recovery methods with different assurance properties and requires notification when account recovery occurs. Knowledge-based questions are not an acceptable authentication factor because answers can often be discovered, guessed, or reused. Help-desk staff should not approve a reset merely because a caller knows information available in company directories, prior email, or public records.\n\nDocument the recovery paths for a forgotten password, lost authenticator, replaced phone, departed administrator, unavailable identity provider, and suspected compromise. Identify which records establish identity, who may approve an exception, how the event is logged, and which independent channel receives notification. Recovery codes and spare authenticators need controlled issuance, storage, use, and revocation.\n\n## DSE recommendation: migrate policy by system\n\n- Inventory identity stores and applications, including maximum length, unsupported characters, silent truncation, lockout behavior, password-history rules, and synchronization dependencies.\n\n- For compatible systems, favor length and blocklist screening over predictable composition and routine expiration rules. Allow password-manager generation, paste, and autofill.\n\n- Apply rate limits and monitoring that slow automated guessing without enabling easy denial of service. Protect reset endpoints as carefully as sign-in.\n\n- Require a password change after credible compromise, exposure in a validated breach source, or an administrator-directed recovery—not merely because a calendar interval elapsed.\n\n- Separate help-desk verification from approval for privileged or high-impact recovery. Notify the account owner through an independent registered channel and retain the event record.\n\n- Test password changes, synchronization, service accounts, emergency access, lost-device recovery, and rollback in a pilot group before broad enforcement.\n\nMeasure compromised-password blocks, recovery attempts, exception use, lockouts, failed synchronization, and confirmed takeover. Preserve stricter rules where a governing authority requires them, and record systems that cannot yet support the target policy with an owner and remediation plan." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo.png" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "url": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-07-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Modern password policy: strengthen sign-in without weakening account recovery", "item": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/#article", "identifier": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "url": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/", "headline": "Modern password policy: strengthen sign-in without weakening account recovery", "description": "Modern password policy emphasizes length, compromised-password screening, rate limiting, password-manager compatibility, and evidence-based changes…", "abstract": "Modern password policy emphasizes length, compromised-password screening, rate limiting, password-manager compatibility, and evidence-based changes while treating account recovery as a separate high-risk control.", "articleBody": "Source fact: current password guidance has changed\nNIST SP 800-63B-4 says a password used as the only authentication factor must contain at least 15 characters. A password used only within multifactor authentication may be at least eight characters, and verifiers should permit at least 64 characters. NIST says verifiers should not impose composition rules, such as requiring mixtures of character types, and should not require periodic password changes unless there is evidence that an authenticator has been compromised. These requirements are written for federal digital identity systems; other organizations can use them as an evidence-based design reference while still checking applicable contracts, regulations, and product limits.\nNIST requires prospective passwords to be compared with a blocklist containing commonly used, expected, or compromised values. It also calls for rate limiting of failed attempts and permits password managers, autofill, and paste. The complete requirements and implementation notes are in NIST SP 800-63B-4. The guidance does not mean that a long password alone is phishing-resistant or that every legacy system can safely accept a policy change without testing.\n\nTreat recovery as another authentication path\nA strong primary authenticator can be undermined by weak recovery. NIST describes recovery methods with different assurance properties and requires notification when account recovery occurs. Knowledge-based questions are not an acceptable authentication factor because answers can often be discovered, guessed, or reused. Help-desk staff should not approve a reset merely because a caller knows information available in company directories, prior email, or public records.\nDocument the recovery paths for a forgotten password, lost authenticator, replaced phone, departed administrator, unavailable identity provider, and suspected compromise. Identify which records establish identity, who may approve an exception, how the event is logged, and which independent channel receives notification. Recovery codes and spare authenticators need controlled issuance, storage, use, and revocation.\n\nDSE recommendation: migrate policy by system\n\nInventory identity stores and applications, including maximum length, unsupported characters, silent truncation, lockout behavior, password-history rules, and synchronization dependencies.\nFor compatible systems, favor length and blocklist screening over predictable composition and routine expiration rules. Allow password-manager generation, paste, and autofill.\nApply rate limits and monitoring that slow automated guessing without enabling easy denial of service. Protect reset endpoints as carefully as sign-in.\nRequire a password change after credible compromise, exposure in a validated breach source, or an administrator-directed recovery—not merely because a calendar interval elapsed.\nSeparate help-desk verification from approval for privileged or high-impact recovery. Notify the account owner through an independent registered channel and retain the event record.\nTest password changes, synchronization, service accounts, emergency access, lost-device recovery, and rollback in a pilot group before broad enforcement.\n\nMeasure compromised-password blocks, recovery attempts, exception use, lockouts, failed synchronization, and confirmed takeover. Preserve stricter rules where a governing authority requires them, and record systems that cannot yet support the target policy with an owner and remediation plan.", "datePublished": "2026-07-28T14:22:00+00:00", "dateModified": "2026-07-28T14:22:00+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@id": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": "https://update.dsesecurity.com/assets/dse-updates-share.png", "articleSection": [ "Cybersecurity", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "Microsoft 365 & Identity", "Guide", "Important priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 471, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "NIST SP 800-63B-4: Authentication and Authenticator Management", "url": "https://csrc.nist.gov/pubs/sp/800/63/b/4/final", "datePublished": "2025-07-31" } } ] } }