{"id":248228,"date":"2026-08-14T00:30:24","date_gmt":"2026-08-14T00:30:24","guid":{"rendered":"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/"},"modified":"2026-08-14T00:30:26","modified_gmt":"2026-08-14T00:30:26","slug":"mitigating-authentication-fatigue","status":"publish","type":"post","link":"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/","title":{"rendered":"How to Mitigate Authentication Fatigue in Your Organization"},"content":{"rendered":"<div class=\"336cb5b64765e27a1a6c1bb71b941f1a\" data-index=\"1\" style=\"float: none; margin:10px 0 10px 0; text-align:center;\">\n<script async src=\"https:\/\/pagead2.googlesyndication.com\/pagead\/js\/adsbygoogle.js?client=ca-pub-4830628043307652\"\r\n     crossorigin=\"anonymous\"><\/script>\r\n<!-- above content -->\r\n<ins class=\"adsbygoogle\"\r\n     style=\"display:block\"\r\n     data-ad-client=\"ca-pub-4830628043307652\"\r\n     data-ad-slot=\"5864845439\"\r\n     data-ad-format=\"auto\"\r\n     data-full-width-responsive=\"true\"><\/ins>\r\n<script>\r\n     (adsbygoogle = window.adsbygoogle || []).push({});\r\n<\/script>\n<\/div>\n<\/p>\n<p>Mitigating authentication fatigue starts with three controls you can assign today: enable number matching on every push-based MFA prompt, pilot FIDO2\/WebAuthn passkeys for your highest-risk roles, and audit how many push prompts your users receive per session. Those three moves address the immediate attack surface. The longer-term architecture is phishing-resistant MFA built on FIDO2\/WebAuthn and hardware security keys, layered with adaptive risk-based step-up, SSO to reduce total prompt volume, and hardened recovery paths that do not become a backdoor.<\/p>\n<p>Immediate priorities for IT teams:<\/p>\n<ul>\n<li><strong>Enable number matching on push MFA today.<\/strong> <a href=\"https:\/\/www.cisa.gov\/sites\/default\/files\/publications\/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">CISA\u2019s number-matching fact sheet<\/a> calls this the recommended interim mitigation for push-based MFA when a full migration to phishing-resistant MFA isn\u2019t yet feasible.<\/li>\n<li><strong>Audit and cap push prompts per session.<\/strong> Set a rate limit of a few prompts before lockout or step-up and alert on denied-push spikes in your identity dashboard.<\/li>\n<li><strong>Pilot passkeys or FIDO2 hardware keys for privileged accounts and high-risk roles.<\/strong> <a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/SpecialPublications\/NIST.SP.800-63B-4.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">NIST SP 800-63B<\/a> explicitly discourages blind-approval out-of-band flows and requires session-bound, cryptographic proof of intent.<\/li>\n<\/ul>\n<p><strong>Pro Tip:<\/strong> <em>Don\u2019t wait for a full platform migration to get value from FIDO2. A 10-person pilot covering your IT admins and finance leads can run in two weeks and gives you real telemetry before you commit to a broader rollout.<\/em><\/p>\n<hr>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_77 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Key_Takeaways\" >Key Takeaways<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#What_MFA_fatigue_push_bombing_is_and_why_it_matters\" >What MFA fatigue (push bombing) is and why it matters<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#How_attackers_exploit_MFA_fatigue_the_attack_flow\" >How attackers exploit MFA fatigue: the attack flow<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Signs_and_telemetry_that_show_users_are_experiencing_authentication_fatigue\" >Signs and telemetry that show users are experiencing authentication fatigue<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Core_mitigations_and_best_practices_prioritized_for_impact_and_effort\" >Core mitigations and best practices, prioritized for impact and effort<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Tier_1_Phishing-resistant_MFA_highest_impact_longer_runway\" >Tier 1: Phishing-resistant MFA (highest impact, longer runway)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Tier_2_Immediate_push-bombing_mitigations\" >Tier 2: Immediate push-bombing mitigations<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Tier_3_Adaptive_and_risk-based_controls\" >Tier 3: Adaptive and risk-based controls<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Tier_4_Operational_UX_changes\" >Tier 4: Operational UX changes<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Implementation_checklist_step-by-step_actions_and_metrics_to_watch\" >Implementation checklist: step-by-step actions and metrics to watch<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Phase_1_Assess_days_1%E2%80%933\" >Phase 1: Assess (days 1\u20133)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Phase_2_Quick_wins_days_4%E2%80%9310\" >Phase 2: Quick wins (days 4\u201310)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Phase_3_Pilot_weeks_2%E2%80%938\" >Phase 3: Pilot (weeks 2\u20138)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Phase_4_Rollout_months_2%E2%80%936\" >Phase 4: Rollout (months 2\u20136)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Phase_5_Iterate_ongoing\" >Phase 5: Iterate (ongoing)<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#User_education_reporting_and_organizational_processes\" >User education, reporting, and organizational processes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Vendor_features_and_configuration_checklist\" >Vendor features and configuration checklist<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#What_CISA_NIST_and_OWASP_say_about_reducing_MFA_fatigue\" >What CISA, NIST, and OWASP say about reducing MFA fatigue<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-19\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Lessons_from_incidents_what_went_wrong_and_what_fixed_it\" >Lessons from incidents: what went wrong and what fixed it<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-20\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#The_case_for_making_security_the_path_of_least_resistance\" >The case for making security the path of least resistance<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-21\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Logmeonce_brings_these_mitigations_together_in_one_platform\" >Logmeonce brings these mitigations together in one platform<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-22\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Sources\" >Sources<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-23\" href=\"https:\/\/logmeonce.com\/resources\/mitigating-authentication-fatigue\/#Recommended\" >Recommended<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"key-takeaways\"><span class=\"ez-toc-section\" id=\"Key_Takeaways\"><\/span>Key Takeaways<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Phishing-resistant MFA (FIDO2\/WebAuthn) combined with number matching and SSO consolidation is the most effective architecture for reducing authentication fatigue while closing the push-bombing attack vector.<\/p>\n<table>\n<thead>\n<tr>\n<th>Point<\/th>\n<th>Details<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Enable number matching first<\/td>\n<td>CISA recommends number matching as the immediate interim control for push-based MFA; it breaks single-tap blind approval.<\/td>\n<\/tr>\n<tr>\n<td>Rate-limit push prompts<\/td>\n<td>Cap prompts at 3\u20135 per session and alert on denied-push spikes to catch push-bombing campaigns early.<\/td>\n<\/tr>\n<tr>\n<td>Pilot FIDO2 for privileged roles<\/td>\n<td>Start with IT admins and finance; FIDO2 eliminates push prompts entirely for enrolled users.<\/td>\n<\/tr>\n<tr>\n<td>Consolidate via SSO<\/td>\n<td>Fewer separate authentication events per day means fewer opportunities for fatigue and fewer attack surfaces.<\/td>\n<\/tr>\n<tr>\n<td>Logmeonce for integrated control<\/td>\n<td>Logmeonce provides passwordless MFA, SSO, session controls, and telemetry in a single enterprise platform.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<hr>\n<h2 id=\"what-mfa-fatigue-push-bombing-is-and-why-it-matters\"><span class=\"ez-toc-section\" id=\"What_MFA_fatigue_push_bombing_is_and_why_it_matters\"><\/span>What MFA fatigue (push bombing) is and why it matters<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>MFA fatigue, often called push bombing, is what happens when an attacker who already has a user\u2019s password floods that user\u2019s authenticator app with rapid-fire approval requests. The goal isn\u2019t to guess the code. The goal is to wear the user down until they tap \u201cApprove\u201d just to make the notifications stop.<\/p>\n<p>That\u2019s the key difference from ordinary MFA friction. Normal friction is a single prompt at login. Push bombing is a deliberate, high-volume attack that exploits the human tendency to comply under pressure or simply to silence an annoyance.<\/p>\n<p>The security impact is direct: one accidental approval hands an attacker an authenticated session. But the business cost runs deeper. A <a href=\"https:\/\/discovery.ucl.ac.uk\/id\/eprint\/1434817\/1\/The_Great_Authentication_Fatigue_Sasse_Krol.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">UCL field study on authentication fatigue<\/a> found that repeated authentication tasks disrupt productivity and push employees toward coping strategies that increase risk, including password reuse, shared credentials, and batching tasks to avoid repeated logins. Help-desk costs climb alongside user frustration, and security teams end up chasing incidents that a design change could have prevented.<\/p>\n<p>Consider a realistic scenario: a mid-level finance analyst receives 15 push notifications over 20 minutes while trying to meet a deadline. She\u2019s already authenticated twice that morning. On the 16th prompt, she taps \u201cApprove\u201d without reading it. The attacker now has a valid session tied to her credentials and access to the financial systems she uses daily.<\/p>\n<hr>\n<h2 id=\"how-attackers-exploit-mfa-fatigue-the-attack-flow\"><span class=\"ez-toc-section\" id=\"How_attackers_exploit_MFA_fatigue_the_attack_flow\"><\/span>How attackers exploit MFA fatigue: the attack flow<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The attack sequence is straightforward, which is part of why it works.<\/p>\n<ol>\n<li><strong>Credential acquisition.<\/strong> The attacker obtains a valid username and password through phishing, credential stuffing, or a prior data breach.<\/li>\n<li><strong>Automated push flood.<\/strong> Using the stolen credentials, the attacker triggers repeated MFA push requests to the victim\u2019s registered device, sometimes dozens within minutes.<\/li>\n<li><strong>Social engineering overlay (optional).<\/strong> Some attackers call or message the target, impersonating IT support, and instruct them to approve the prompt to \u201cresolve a login issue.\u201d<\/li>\n<li><strong>User approval.<\/strong> The victim approves one prompt, either from fatigue, confusion, or social pressure.<\/li>\n<li><strong>Session takeover.<\/strong> The attacker gains an authenticated session and moves laterally, exfiltrates data, or establishes persistence.<\/li>\n<\/ol>\n<p><a href=\"https:\/\/attack.mitre.org\/techniques\/T1621\/\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">MITRE ATT&amp;CK catalogs this as technique T1621<\/a>, Multi-Factor Authentication Request Generation, and describes it as an attacker technique specifically designed to coerce user approval through volume.<\/p>\n<p>Variants include pure push bombing (volume alone), credential stuffing followed by targeted push, and hybrid attacks that combine persistent prompts with a phone call. The hybrid version is particularly effective because it adds a plausible authority figure to the pressure.<\/p>\n<p>A 2022 Microsoft security blog analysis of the DEV-0537 (Lapsus$) group documented exactly this pattern: attackers used push bombing combined with social engineering calls to compromise accounts at multiple organizations. The remediation lesson from that incident was consistent across every affected environment: rate-limit push prompts, add number matching, and monitor denied-push telemetry.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>Single-tap approval push notifications are the highest-risk design. Any prompt that requires no cognitive engagement from the user is a prompt an attacker can exploit through volume alone.<\/em><\/p>\n<hr>\n<h2 id=\"signs-and-telemetry-that-show-users-are-experiencing-authentication-fatigue\"><span class=\"ez-toc-section\" id=\"Signs_and_telemetry_that_show_users_are_experiencing_authentication_fatigue\"><\/span>Signs and telemetry that show users are experiencing authentication fatigue<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Behavioral signals usually appear before an incident does. The challenge is that most organizations aren\u2019t collecting the right telemetry to see them.<\/p>\n<p><strong>Behavioral indicators to watch for:<\/strong><\/p>\n<ul>\n<li>Rising volume of denied push notifications per user or per group<\/li>\n<li>Users approving prompts after a long string of denials in the same session (the \u201cfinally gave up\u201d pattern)<\/li>\n<li>Increased help-desk tickets about login problems, locked accounts, or \u201cI keep getting MFA requests I didn\u2019t initiate\u201d<\/li>\n<li>Reports of shared credentials or users logging in from each other\u2019s devices to avoid repeated prompts<\/li>\n<li>Employees disabling MFA where self-service allows it<\/li>\n<\/ul>\n<p><strong>Telemetry metrics to instrument:<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Metric<\/th>\n<th>What it signals<\/th>\n<th>Suggested threshold<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Denied push rate per user\/day<\/td>\n<td>Fatigue or active attack<\/td>\n<td>Alert above 5 denials\/day<\/td>\n<\/tr>\n<tr>\n<td>Prompt acceptance after 3+ prompts<\/td>\n<td>Blind approval behavior<\/td>\n<td>Flag any session with 3+ prompts before accept<\/td>\n<\/tr>\n<tr>\n<td>Average prompts per authentication session<\/td>\n<td>Excessive friction<\/td>\n<td>Investigate if average exceeds 2<\/td>\n<\/tr>\n<tr>\n<td>Help-desk MFA tickets per user\/month<\/td>\n<td>Systemic friction<\/td>\n<td>Baseline, then track trend<\/td>\n<\/tr>\n<tr>\n<td>Denied-push spikes across user groups<\/td>\n<td>Coordinated push-bombing<\/td>\n<td>Alert on sudden group-level spikes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1786429095973_Diagram-showing-MFA-fatigue-telemetry-metrics-and-thresholds.jpeg\" alt=\"Diagram showing MFA fatigue telemetry metrics and thresholds\" title=\"\"><\/p>\n<p>Start by pulling denied-push logs from your identity provider. Most enterprise platforms (Azure AD, Okta, Ping) surface these in their audit logs. If you\u2019re not already routing those signals into your SIEM or identity dashboard, that\u2019s the first instrumentation task.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>Set a baseline for denied-push rate during a quiet two-week period, then use that baseline to calibrate your alert thresholds. A threshold without a baseline is just a guess.<\/em><\/p>\n<hr>\n<h2 id=\"core-mitigations-and-best-practices-prioritized-for-impact-and-effort\"><span class=\"ez-toc-section\" id=\"Core_mitigations_and_best_practices_prioritized_for_impact_and_effort\"><\/span>Core mitigations and best practices, prioritized for impact and effort<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The mitigations below are ordered by security impact and deployment speed. Work through them in sequence, but don\u2019t let perfect be the enemy of good: number matching alone, deployed this week, meaningfully reduces your push-bombing exposure.<\/p>\n<h3 id=\"tier-1-phishing-resistant-mfa-highest-impact-longer-runway\"><span class=\"ez-toc-section\" id=\"Tier_1_Phishing-resistant_MFA_highest_impact_longer_runway\"><\/span>Tier 1: Phishing-resistant MFA (highest impact, longer runway)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><strong>FIDO2\/WebAuthn and hardware security keys<\/strong> are the architectural endpoint. FIDO2 binds the authentication cryptographically to the origin, so a push-bombing attack against a FIDO2 user simply doesn\u2019t work. There\u2019s no push to approve. The <a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/Authentication_Cheat_Sheet.html\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">OWASP Authentication Cheat Sheet<\/a> recommends moving away from weak authenticators (SMS, simple push) toward cryptographic authenticators, and CISA\u2019s guidance places phishing-resistant MFA at the top of its recommendation hierarchy.<\/p>\n<p>Hardware security keys (USB\/NFC form factors like those from the FIDO Alliance ecosystem) are the right choice for privileged accounts, IT admins, and any role with access to sensitive systems. Passkeys, the FIDO2-based consumer-friendly variant, work well for broader workforce rollout where hardware distribution is impractical.<\/p>\n<h3 id=\"tier-2-immediate-push-bombing-mitigations\"><span class=\"ez-toc-section\" id=\"Tier_2_Immediate_push-bombing_mitigations\"><\/span>Tier 2: Immediate push-bombing mitigations<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li><strong>Number matching:<\/strong> Requires the user to type a code displayed on the sign-in screen into their authenticator app, breaking the single-tap approval flow. Microsoft\u2019s Azure AD documentation shows exactly how to enable this in a few configuration steps.<\/li>\n<li><strong>Rate-limit push prompts:<\/strong> Cap the number of push requests per authentication attempt (3\u20135 is a common policy) and lock the account or require step-up after the limit is hit.<\/li>\n<li><strong>Disable auto-approve flows:<\/strong> Any push configuration that allows approval without active user input should be disabled.<\/li>\n<\/ul>\n<h3 id=\"tier-3-adaptive-and-risk-based-controls\"><span class=\"ez-toc-section\" id=\"Tier_3_Adaptive_and_risk-based_controls\"><\/span>Tier 3: Adaptive and risk-based controls<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Risk-based step-up authentication evaluates signals like device posture, location, login time, and behavioral patterns before deciding which factor to require. A user logging in from a known device on a corporate network during business hours gets a lighter challenge. The same user logging in from an unknown device in a new country at 2 AM gets a harder one. Adaptive authentication approaches reduce total prompt volume for low-risk sessions while concentrating friction where it matters.<\/p>\n<h3 id=\"tier-4-operational-ux-changes\"><span class=\"ez-toc-section\" id=\"Tier_4_Operational_UX_changes\"><\/span>Tier 4: Operational UX changes<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>SSO reduces the number of separate authentication events a user faces per day. A user who authenticates once to an SSO provider and then moves freely between applications generates far fewer prompts than one who re-authenticates per application. Session lifetime policies matter too: sessions that expire too aggressively force re-authentication unnecessarily, while sessions that never expire create their own risk. Find the middle ground based on your risk profile and user workflows.<\/p>\n<p>Recovery path hardening is often overlooked. A strong MFA posture is undermined if the account recovery flow accepts a simple email link or a security question. Harden recovery to require the same or stronger authentication as the primary login path.<\/p>\n<p><strong>Prioritization by organization size:<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Priority<\/th>\n<th>Control<\/th>\n<th>Small org (under 500 users)<\/th>\n<th>Mid-size (200\u20132,000)<\/th>\n<th>Enterprise (thousands+)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>1<\/td>\n<td>Number matching on push<\/td>\n<td>Enable immediately<\/td>\n<td>Enable immediately<\/td>\n<td>Enable immediately<\/td>\n<\/tr>\n<tr>\n<td>2<\/td>\n<td>Rate-limit push prompts<\/td>\n<td>Configure in IdP<\/td>\n<td>Configure in IdP<\/td>\n<td>Configure in IdP + SIEM alert<\/td>\n<\/tr>\n<tr>\n<td>3<\/td>\n<td>SSO consolidation<\/td>\n<td>Start with top 5 apps<\/td>\n<td>Phased by department<\/td>\n<td>Full IdP-driven SSO<\/td>\n<\/tr>\n<tr>\n<td>4<\/td>\n<td>FIDO2 pilot<\/td>\n<td>IT admins first<\/td>\n<td>IT + finance + execs<\/td>\n<td>All privileged roles<\/td>\n<\/tr>\n<tr>\n<td>5<\/td>\n<td>Adaptive\/risk-based auth<\/td>\n<td>Use IdP built-in rules<\/td>\n<td>Dedicated policy engine<\/td>\n<td>Full UEBA integration<\/td>\n<\/tr>\n<tr>\n<td>6<\/td>\n<td>Hardware security keys<\/td>\n<td>Admins only<\/td>\n<td>Privileged roles<\/td>\n<td>All high-risk roles<\/td>\n<\/tr>\n<tr>\n<td>7<\/td>\n<td>Recovery path hardening<\/td>\n<td>Audit and fix weak resets<\/td>\n<td>Policy + runbook<\/td>\n<td>Automated enforcement<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Pro Tip:<\/strong> <em>Stage your FIDO2 pilot with a volunteer group from IT. They\u2019ll find the enrollment friction, the edge cases with legacy apps, and the help-desk scripts you need before you roll it out to 500 people who have a deadline.<\/em><\/p>\n<hr>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1786429173421_Tier-4-Operational-UX-changes-overview-diagram.jpeg\" alt=\"Tier 4: Operational UX changes \u2014 overview diagram\" title=\"\"><\/p>\n<h2 id=\"implementation-checklist-step-by-step-actions-and-metrics-to-watch\"><span class=\"ez-toc-section\" id=\"Implementation_checklist_step-by-step_actions_and_metrics_to_watch\"><\/span>Implementation checklist: step-by-step actions and metrics to watch<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3 id=\"phase-1-assess-days-13\"><span class=\"ez-toc-section\" id=\"Phase_1_Assess_days_1%E2%80%933\"><\/span>Phase 1: Assess (days 1\u20133)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li>Inventory all applications and their current MFA methods.<\/li>\n<li>Pull denied-push logs and establish a baseline for the five telemetry metrics above.<\/li>\n<li>Identify your highest-risk roles (admins, finance, executives, developers with production access).<\/li>\n<li>Document which applications support FIDO2\/WebAuthn and which are limited to push or SMS.<\/li>\n<\/ul>\n<h3 id=\"phase-2-quick-wins-days-410\"><span class=\"ez-toc-section\" id=\"Phase_2_Quick_wins_days_4%E2%80%9310\"><\/span>Phase 2: Quick wins (days 4\u201310)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li>Enable number matching on all push-based MFA. For Azure AD environments, follow <a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/active-directory\/authentication\/how-to-mfa-number-match\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Microsoft\u2019s number-matching configuration guide<\/a>.<\/li>\n<li>Set push rate limits (3\u20135 prompts max before lockout or step-up).<\/li>\n<li>Review and tighten session lifetime policies for your highest-risk applications.<\/li>\n<li>Send a brief user communication explaining the number-matching change and why it matters.<\/li>\n<\/ul>\n<h3 id=\"phase-3-pilot-weeks-28\"><span class=\"ez-toc-section\" id=\"Phase_3_Pilot_weeks_2%E2%80%938\"><\/span>Phase 3: Pilot (weeks 2\u20138)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li>Enroll your IT admin group in FIDO2\/passkey authentication.<\/li>\n<li>Run for two to four weeks, collecting support tickets, enrollment success rates, and denied-push rates.<\/li>\n<li>Document edge cases: legacy VPN clients, mobile apps that don\u2019t support FIDO2, shared workstations.<\/li>\n<li>Define acceptance criteria before expanding: target less than one MFA-related support ticket per 50 users per week.<\/li>\n<\/ul>\n<h3 id=\"phase-4-rollout-months-26\"><span class=\"ez-toc-section\" id=\"Phase_4_Rollout_months_2%E2%80%936\"><\/span>Phase 4: Rollout (months 2\u20136)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li>Expand FIDO2\/passkeys to all privileged roles, then to broader workforce groups.<\/li>\n<li>Deploy SSO for the top 10\u201320 applications by login frequency to reduce total prompt volume.<\/li>\n<li>Integrate denied-push telemetry into your SIEM and set automated alerts for push-bombing patterns.<\/li>\n<li>Update onboarding and offboarding runbooks to include MFA enrollment and de-provisioning steps.<\/li>\n<\/ul>\n<h3 id=\"phase-5-iterate-ongoing\"><span class=\"ez-toc-section\" id=\"Phase_5_Iterate_ongoing\"><\/span>Phase 5: Iterate (ongoing)<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<ul>\n<li>Review MFA telemetry monthly. Track denied-push rate, prompts per session, and help-desk ticket volume.<\/li>\n<li>Conduct quarterly reviews of which applications still use push or SMS and set migration targets.<\/li>\n<li>Adjust session policies and risk-based rules based on observed user behavior and incident data.<\/li>\n<\/ul>\n<p><strong>Timeline summary:<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Phase<\/th>\n<th>Timeline<\/th>\n<th>Key milestone<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Assess<\/td>\n<td>Days 1\u20133<\/td>\n<td>Baseline telemetry established<\/td>\n<\/tr>\n<tr>\n<td>Quick wins<\/td>\n<td>Days 4\u201310<\/td>\n<td>Number matching live, push rate limits set<\/td>\n<\/tr>\n<tr>\n<td>Pilot<\/td>\n<td>Weeks 2\u20138<\/td>\n<td>FIDO2 pilot running for IT admins<\/td>\n<\/tr>\n<tr>\n<td>Rollout<\/td>\n<td>Months 2\u20136<\/td>\n<td>Privileged roles on passkeys, SSO expanded<\/td>\n<\/tr>\n<tr>\n<td>Iterate<\/td>\n<td>Ongoing<\/td>\n<td>Monthly telemetry review, quarterly MFA audit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<hr>\n<h2 id=\"user-education-reporting-and-organizational-processes\"><span class=\"ez-toc-section\" id=\"User_education_reporting_and_organizational_processes\"><\/span>User education, reporting, and organizational processes<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Training users to recognize push bombing is as important as the technical controls. A user who understands what\u2019s happening will deny and report. A user who doesn\u2019t will eventually approve.<\/p>\n<p><strong>Core training talking points:<\/strong><\/p>\n<ul>\n<li>What a push notification you didn\u2019t initiate looks like, and why it\u2019s a red flag.<\/li>\n<li>The number-matching mechanic: if the number on your screen doesn\u2019t match the number in your app, deny and report immediately.<\/li>\n<li>Never approve a prompt because someone on the phone or in a chat tells you to, regardless of who they claim to be.<\/li>\n<li>Denying a prompt is the right action. It doesn\u2019t break anything. Report it to the help desk.<\/li>\n<\/ul>\n<p><strong>Reporting playbook:<\/strong><\/p>\n<ol>\n<li>User denies the unexpected push.<\/li>\n<li>User reports via a dedicated channel (Slack\/Teams channel, email alias, or ticketing system) with the time and their username.<\/li>\n<li>Help desk logs the report and checks the identity provider\u2019s audit log for the source IP and authentication attempt details.<\/li>\n<li>If the denied-push count for that user exceeds the alert threshold, the SOC is notified automatically.<\/li>\n<li>The account is reviewed for compromise indicators: recent password changes, new registered devices, unusual access patterns.<\/li>\n<\/ol>\n<p><strong>Pro Tip:<\/strong> <em>Make the reporting path frictionless. A one-click \u201cReport suspicious MFA\u201d button in your company\u2019s Slack or Teams workspace gets far more reports than an email alias buried in the IT wiki.<\/em><\/p>\n<p><strong>Process recommendations:<\/strong><\/p>\n<ul>\n<li>Embed MFA enrollment and push-bombing awareness into new-hire onboarding.<\/li>\n<li>Include MFA de-provisioning in offboarding checklists to prevent orphaned authenticators.<\/li>\n<li>Run a quarterly review of denied-push trends and use the data to adjust rate limits and session policies.<\/li>\n<li>Update help-desk runbooks annually to reflect current MFA configurations and escalation paths.<\/li>\n<\/ul>\n<hr>\n<h2 id=\"vendor-features-and-configuration-checklist\"><span class=\"ez-toc-section\" id=\"Vendor_features_and_configuration_checklist\"><\/span>Vendor features and configuration checklist<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>When evaluating or reconfiguring an identity provider or MFA platform, these are the specific capabilities to verify before you commit.<\/p>\n<p><strong>Feature checklist:<\/strong><\/p>\n<ul>\n<li>Number matching support on push notifications (not just available, but enabled by default or easily configurable)<\/li>\n<li>FIDO2\/WebAuthn support for both web and native mobile applications<\/li>\n<li>Hardware security key management (enrollment, revocation, backup key policies)<\/li>\n<li>Adaptive risk scoring with configurable signals (device, location, behavior)<\/li>\n<li>Push rate limiting with configurable thresholds and lockout behavior<\/li>\n<li>Session binding: can push prompts be tied to a specific session ID or transaction context?<\/li>\n<li>Denied-push telemetry exposed via API or SIEM integration<\/li>\n<li>Robust, phishing-resistant recovery flows (not just email link or security questions)<\/li>\n<\/ul>\n<p><strong>Questions to ask vendors:<\/strong><\/p>\n<ol>\n<li>Does your push MFA support number matching, and is it enabled by default?<\/li>\n<li>Can you bind push prompts to a specific session or transaction ID to prevent replay?<\/li>\n<li>What rate limits exist on push requests, and are they configurable per policy group?<\/li>\n<li>How do you surface denied-push telemetry, and does it integrate with standard SIEM formats?<\/li>\n<li>What FIDO2 authenticator types do you support, and how do you handle cross-platform passkey sync?<\/li>\n<li>What does your account recovery flow require, and can it be hardened to match primary authentication strength?<\/li>\n<\/ol>\n<p><strong>Pro Tip:<\/strong> <em>Ask vendors for a demo of their denied-push alerting specifically. Many platforms log the data but don\u2019t surface it in a usable dashboard. If the vendor can\u2019t show you a denied-push spike in under two minutes, assume you\u2019ll be building that view yourself.<\/em><\/p>\n<p><strong>Integration challenges to anticipate:<\/strong><\/p>\n<ul>\n<li>Legacy applications that don\u2019t support FIDO2 will need a bridge (SAML\/OIDC proxy or a password manager with SSO) to participate in a passkey rollout.<\/li>\n<li>Mobile device management (MDM) enrollment is a prerequisite for device-bound passkeys on mobile; users without enrolled devices will need an alternative path.<\/li>\n<li>Cross-platform passkey sync (Apple Passkeys, Google Password Manager, Windows Hello) works well within ecosystems but has friction at the boundaries. Plan for users who switch between platforms.<\/li>\n<\/ul>\n<p><strong>Pro Tip:<\/strong> <em>For <a href=\"https:\/\/logmeonce.com\/enterprise-password-management-1\" target=\"_blank\" rel=\"noopener\">enterprise password management<\/a> environments, verify that your password manager can act as a FIDO2 authenticator or at minimum as an SSO bridge for legacy apps. That single capability eliminates most of the \u201cwe can\u2019t migrate this app\u201d objections.<\/em><\/p>\n<hr>\n<h2 id=\"what-cisa-nist-and-owasp-say-about-reducing-mfa-fatigue\"><span class=\"ez-toc-section\" id=\"What_CISA_NIST_and_OWASP_say_about_reducing_MFA_fatigue\"><\/span>What CISA, NIST, and OWASP say about reducing MFA fatigue<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The three authoritative sources on this topic are aligned, and their guidance is more specific than most organizations realize.<\/p>\n<p><strong>CISA<\/strong> is direct: prefer phishing-resistant MFA. Where that\u2019s not immediately feasible, implement number matching on push-based MFA as an interim control. CISA\u2019s fact sheet also specifies that organizations should train users to report unknown or bulk confirmation requests and that security teams should investigate denied-push patterns as potential attack indicators.<\/p>\n<p><strong>NIST SP 800-63B<\/strong> addresses the mechanism directly. The guidance discourages out-of-band authentication schemes that allow blind approval and requires that authentication demonstrate intent through session-bound or cryptographic proof. In plain terms: a push notification that requires only a single tap, with no connection to the specific session being authenticated, does not meet the intent-to-authenticate standard NIST describes. Number matching is the minimum; FIDO2 cryptographic binding is the target.<\/p>\n<p><strong>OWASP<\/strong> takes a similar position. The Authentication Cheat Sheet recommends abandoning ineffective mandatory password rotation, planning for authenticator agility, and favoring cryptographic authenticators over SMS or simple push. OWASP also flags usability: an authentication system that users find so burdensome they route around it has failed, regardless of its theoretical security properties.<\/p>\n<p>The convergence across CISA, NIST, and OWASP is notable. All three point to the same destination: cryptographic, phishing-resistant authentication. The path there runs through number matching, rate limiting, and SSO consolidation.<\/p>\n<hr>\n<h2 id=\"lessons-from-incidents-what-went-wrong-and-what-fixed-it\"><span class=\"ez-toc-section\" id=\"Lessons_from_incidents_what_went_wrong_and_what_fixed_it\"><\/span>Lessons from incidents: what went wrong and what fixed it<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The Lapsus$ group\u2019s 2022 campaign, analyzed in detail by Microsoft\u2019s security team, is the clearest documented example of push bombing at scale. Attackers obtained credentials through social engineering and data purchases, then triggered repeated MFA push requests to target users. In several cases, they combined the push flood with a phone call impersonating IT support, instructing users to approve the prompt. The technique worked because the push design required no cognitive engagement: one tap, no context, no session binding.<\/p>\n<p><strong>What went wrong in these environments:<\/strong><\/p>\n<ul>\n<li>Push prompts had no number matching or session context, making blind approval trivially easy.<\/li>\n<li>No rate limits on push requests meant attackers could sustain the flood indefinitely.<\/li>\n<li>Denied-push events weren\u2019t generating alerts, so the SOC had no visibility into the attack in progress.<\/li>\n<li>Recovery flows in some cases were weaker than the primary authentication, giving attackers an alternative path.<\/li>\n<\/ul>\n<p><strong>Remediation steps that followed:<\/strong><\/p>\n<ol>\n<li>Enable number matching on all push-based MFA immediately.<\/li>\n<li>Set push rate limits and automatic account lockout after threshold breaches.<\/li>\n<li>Route denied-push telemetry to the SIEM with automated alerting.<\/li>\n<li>Audit and harden account recovery flows to require equivalent authentication strength.<\/li>\n<li>Begin FIDO2 migration for privileged accounts.<\/li>\n<\/ol>\n<p><strong>Pro Tip:<\/strong> <em>Treat a denied-push spike the same way you\u2019d treat a failed-login spike: as a potential attack in progress, not a user error. Build the alert before you need it.<\/em><\/p>\n<p>The pattern repeats across incidents. Weak push design plus absent telemetry plus strong recovery paths equals a reliable attack vector. Each of those three failures has a direct technical fix.<\/p>\n<hr>\n<h2 id=\"the-case-for-making-security-the-path-of-least-resistance\"><span class=\"ez-toc-section\" id=\"The_case_for_making_security_the_path_of_least_resistance\"><\/span>The case for making security the path of least resistance<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Most MFA fatigue discussions focus on the attacker. The more useful frame is the user.<\/p>\n<p>When authentication is genuinely frictionless for legitimate users, push bombing stops working. Not because the attacker can\u2019t send prompts, but because the user never sees them. FIDO2 passkeys don\u2019t generate push notifications. A user who authenticates with a hardware key or a device-bound passkey is simply not reachable by this attack class.<\/p>\n<p>The organizations that have made the most progress on reducing login fatigue share a common approach: they treated the authentication experience as a product problem, not just a security problem. They measured prompt volume per user per day, set targets, and held identity teams accountable for hitting them. SSO consolidation, passkey rollout, and session policy tuning were driven by those metrics, not by incident response.<\/p>\n<p>The UCL authentication fatigue research makes the point clearly: when authentication tasks are too frequent and too disruptive, users don\u2019t become more security-conscious. They find workarounds. The secure path has to be the easy path, or users will find a different path.<\/p>\n<p>That\u2019s the practical argument for investing in FIDO2 and SSO beyond the security benefit. Fewer prompts, less friction, and better user experience all reduce the attack surface at the same time. The <a href=\"https:\/\/logmeonce.com\/your-logmeonce-password-management-benefits\" target=\"_blank\" rel=\"noopener\">password management benefits<\/a> that come from centralizing credentials through a well-configured identity platform compound that effect: users manage fewer secrets, face fewer login events, and have fewer opportunities to make the kind of fatigued mistake attackers are counting on.<\/p>\n<hr>\n<h2 id=\"logmeonce-brings-these-mitigations-together-in-one-platform\"><span class=\"ez-toc-section\" id=\"Logmeonce_brings_these_mitigations_together_in_one_platform\"><\/span>Logmeonce brings these mitigations together in one platform<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Reducing push fatigue requires more than a policy change. It requires an identity platform that supports number matching, FIDO2\/WebAuthn, SSO, adaptive authentication, and the telemetry to measure all of it. That\u2019s where Logmeonce fits into the mitigation playbook described in this guide.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1760417791460_logmeonce.jpg\" alt=\"Logmeonce\" title=\"\"><\/p>\n<p>Logmeonce\u2019s <a href=\"https:\/\/logmeonce.com\/cybersecurity\" target=\"_blank\" rel=\"noopener\">enterprise cybersecurity platform<\/a> covers the full stack: passwordless MFA, SSO across your application portfolio, session controls, and dark web monitoring to catch credential exposure before it becomes a push-bombing opportunity. The enterprise password management layer handles credential centralization and SSO bridging for legacy apps that can\u2019t natively support FIDO2, removing the most common objection to a passkey rollout. You get the telemetry, the controls, and the recovery hardening in one place, without stitching together five separate vendors. Start with a free trial at <a href=\"https:\/\/logmeonce.com\/\" target=\"_blank\" rel=\"noopener\">Logmeonce<\/a> and run the number-matching and SSO configuration against your current environment to see the prompt-volume reduction directly.<\/p>\n<hr>\n<h2 id=\"sources\"><span class=\"ez-toc-section\" id=\"Sources\"><\/span>Sources<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The sources below are the authoritative references for every recommendation in this guide.<\/p>\n<ul>\n<li><a href=\"https:\/\/www.cisa.gov\/sites\/default\/files\/publications\/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Implementing Number Matching in MFA Applications<\/a><\/li>\n<li><a href=\"https:\/\/nvlpubs.nist.gov\/nistpubs\/SpecialPublications\/NIST.SP.800-63B-4.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">NIST.SP.800-63B-4<\/a><\/li>\n<li><a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/Authentication_Cheat_Sheet.html\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Authentication Cheat Sheet<\/a><\/li>\n<li><a href=\"https:\/\/discovery.ucl.ac.uk\/id\/eprint\/1434817\/1\/The_Great_Authentication_Fatigue_Sasse_Krol.pdf\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">The Great Authentication Fatigue (UCL study)<\/a><\/li>\n<li><a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/active-directory\/authentication\/how-to-mfa-number-match\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Implementing Number Matching in Azure AD (Microsoft Learn)<\/a><\/li>\n<\/ul>\n<h2 id=\"recommended\"><span class=\"ez-toc-section\" id=\"Recommended\"><\/span>Recommended<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<ul>\n<li><a href=\"https:\/\/logmeonce.com\/blog\/password-management\/6-reasons-to-take-password-fatigue-seriously-and-how-to-avoid-it\" target=\"_blank\" rel=\"noopener\">6 Reasons to Take Password Fatigue Seriously (And How to Avoid It)<\/a><\/li>\n<\/ul>\n\n<div style=\"font-size: 0px; height: 0px; line-height: 0px; margin: 0; padding: 0; clear: both;\"><\/div>","protected":false},"excerpt":{"rendered":"<p>Learn effective strategies for mitigating authentication fatigue, including key controls to enhance security and reduce user frustration today.<\/p>\n","protected":false},"author":0,"featured_media":248230,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-248228","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-logmeonce"],"acf":[],"_links":{"self":[{"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts\/248228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/comments?post=248228"}],"version-history":[{"count":1,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts\/248228\/revisions"}],"predecessor-version":[{"id":248229,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts\/248228\/revisions\/248229"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/media\/248230"}],"wp:attachment":[{"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/media?parent=248228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/categories?post=248228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/tags?post=248228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}