{"id":248179,"date":"2026-07-28T01:00:38","date_gmt":"2026-07-28T01:00:38","guid":{"rendered":"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/"},"modified":"2026-07-28T01:00:39","modified_gmt":"2026-07-28T01:00:39","slug":"how-to-improve-authentication-security","status":"publish","type":"post","link":"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/","title":{"rendered":"How to Improve Authentication Security: A Practical Guide"},"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<hr>\n<blockquote>\n<p><strong>TL;DR:<\/strong><\/p>\n<ul>\n<li>Enforcing phishing-resistant multi-factor authentication and eliminating hardcoded secrets reduces most organization attack surface.<\/li>\n<li>Implement immediate controls such as MFA on admin portals, TLS encryption everywhere, and breached-password detection within 72 hours.<\/li>\n<\/ul>\n<\/blockquote>\n<hr>\n<p>The fastest way to cut account compromise risk is to enforce phishing-resistant multi-factor authentication and eliminate hardcoded secrets. Those two controls alone address the majority of the attack surface most organizations carry into any given week.<\/p>\n<p>Here is what to do in the first 24\u201372 hours:<\/p>\n<ul>\n<li><strong>Enforce MFA on admin consoles, email, and cloud management portals<\/strong> \u2014 these are the highest-value targets for credential-based attacks.<\/li>\n<li><strong>Block SMS-based second factors for privileged and finance accounts<\/strong> \u2014 SIM-swapping makes SMS a liability for high-risk roles.<\/li>\n<li><strong>Enable TLS everywhere<\/strong> \u2014 no authentication endpoint should accept plaintext connections, full stop.<\/li>\n<li><strong>Scan codebases and CI\/CD pipelines for hardcoded secrets<\/strong> \u2014 API keys and service account credentials embedded in source code are a persistent, often-overlooked exposure.<\/li>\n<li><strong>Enable breached-password detection<\/strong> \u2014 check new and changed passwords against known-compromised credential lists before accepting them.<\/li>\n<\/ul>\n<p>According to <a href=\"https:\/\/cheatsheetseries.owasp.org\/cheatsheets\/Authentication_Cheat_Sheet\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">Microsoft analysis cited by OWASP<\/a>, MFA would have stopped a vast majority of account compromises. That single figure should settle any internal debate about MFA priority.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>When rolling out MFA at speed, use your identity provider\u2019s bulk-enrollment API to push authenticator app enrollment links to all admin accounts simultaneously. Pair that with a 48-hour grace window before enforcement, and you avoid a helpdesk flood while still hitting your deadline.<\/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\/how-to-improve-authentication-security\/#Why_authentication_failures_are_your_most_exploitable_attack_surface\" >Why authentication failures are your most exploitable attack surface<\/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\/how-to-improve-authentication-security\/#How_to_implement_and_harden_MFA_across_critical_systems\" >How to implement and harden MFA across critical systems<\/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\/how-to-improve-authentication-security\/#Password_hygiene_passphrases_and_secure_credential_storage\" >Password hygiene, passphrases, and secure credential storage<\/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\/how-to-improve-authentication-security\/#How_to_secure_tokens_sessions_and_API_credentials\" >How to secure tokens, sessions, and API credentials<\/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\/how-to-improve-authentication-security\/#Transport_cookies_and_platform_hardening_for_authentication_flows\" >Transport, cookies, and platform hardening for authentication flows<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#Modern_options_adaptive_MFA_passwordless_and_FIDO2WebAuthn\" >Modern options: adaptive MFA, passwordless, and FIDO2\/WebAuthn<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#How_to_roll_out_stronger_authentication_at_scale\" >How to roll out stronger authentication at scale<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#Monitoring_detection_and_incident_response_for_authentication_events\" >Monitoring, detection, and incident response for authentication events<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#Common_authentication_problems_and_how_to_fix_them\" >Common authentication problems and how to fix them<\/a><\/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\/how-to-improve-authentication-security\/#Standards_and_evidence_that_validate_these_recommendations\" >Standards and evidence that validate these recommendations<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#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-12\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#The_first_90_days_a_security_leaders_honest_priorities\" >The first 90 days: a security leader\u2019s honest priorities<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#Logmeonce_accelerates_authentication_security_for_security_teams\" >Logmeonce accelerates authentication security for security teams<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#Useful_sources_for_further_reading\" >Useful sources for further reading<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/logmeonce.com\/resources\/how-to-improve-authentication-security\/#The_part_most_guides_skip_recovery_is_where_authentication_actually_fails\" >The part most guides skip: recovery is where authentication actually fails<\/a><\/li><\/ul><\/nav><\/div>\n<h2 id=\"why-authentication-failures-are-your-most-exploitable-attack-surface\"><span class=\"ez-toc-section\" id=\"Why_authentication_failures_are_your_most_exploitable_attack_surface\"><\/span>Why authentication failures are your most exploitable attack surface<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1785003117515_Security-analyst-monitoring-authentication-alerts.jpeg\" alt=\"Security analyst monitoring authentication alerts\" title=\"\"><\/p>\n<p>Strong authentication directly reduces breach risk because most attackers follow the path of least resistance: stolen or guessable credentials. The OWASP Authentication Cheat Sheet identifies broken authentication as one of the most critical web application security risks, and the attacker techniques behind it are well-documented.<\/p>\n<p>The main attack categories your controls need to address:<\/p>\n<ul>\n<li><strong>Credential stuffing:<\/strong> Automated replay of username\/password pairs from previous breaches. Mitigated by rate limiting, breached-password checks, and MFA.<\/li>\n<li><strong>Phishing:<\/strong> Adversary-in-the-middle pages that capture OTPs in real time. Only phishing-resistant factors (FIDO2, hardware keys) fully defeat this.<\/li>\n<li><strong>SIM swapping:<\/strong> Social engineering of mobile carriers to redirect SMS codes. Mitigated by moving high-risk accounts off SMS entirely.<\/li>\n<li><strong>Replay attacks:<\/strong> Reuse of captured tokens or session cookies. Mitigated by short token lifetimes, binding tokens to device context, and TLS.<\/li>\n<li><strong>API key leakage:<\/strong> Secrets committed to version control or exposed in logs. Mitigated by secret management vaults and automated scanning.<\/li>\n<\/ul>\n<p>The operational metrics that tell you where you stand: MFA opt-in rate by user segment, failed login volume by IP and account, password reuse rate from your vault telemetry, and the number of credentials appearing in breach databases. If you are not measuring these, you are flying blind on authentication risk.<\/p>\n<hr>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1785003607277_Infographic-outlining-key-authentication-security-steps.jpeg\" alt=\"Infographic outlining key authentication security steps\" title=\"\"><\/p>\n<h2 id=\"how-to-implement-and-harden-mfa-across-critical-systems\"><span class=\"ez-toc-section\" id=\"How_to_implement_and_harden_MFA_across_critical_systems\"><\/span>How to implement and harden MFA across critical systems<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Enforce phishing-resistant second factors for any account with elevated privileges. For standard users, any MFA is dramatically better than none \u2014 but the factor type matters more than most teams acknowledge.<\/p>\n<p><strong>Factor types, ranked by phishing resistance:<\/strong><\/p>\n<ul>\n<li><strong>Hardware security keys (FIDO2\/WebAuthn):<\/strong> The gold standard. Cryptographically bound to the origin, so a phishing site cannot intercept the credential. Required for AAL3 under <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>.<\/li>\n<li><strong>Authenticator apps (TOTP):<\/strong> Strong and widely supported. Vulnerable to real-time phishing if an attacker proxies the OTP, but far better than SMS.<\/li>\n<li><strong>Push notifications:<\/strong> Convenient, but susceptible to MFA fatigue attacks where attackers spam approval requests until a user accidentally approves one.<\/li>\n<li><strong>SMS OTP:<\/strong> Weakest of the common options. Acceptable for low-risk consumer flows; not acceptable for admin, finance, or privileged operations.<\/li>\n<\/ul>\n<p><strong>Deployment priority \u2014 protect these first:<\/strong><\/p>\n<ol>\n<li>Cloud management consoles (AWS, Azure, GCP)<\/li>\n<li>Identity provider admin accounts<\/li>\n<li>Email and collaboration platforms<\/li>\n<li>Finance and payroll systems<\/li>\n<li>Code repositories and CI\/CD pipelines<\/li>\n<li>VPN and remote access gateways<\/li>\n<\/ol>\n<p>Protecting enrollment is as important as protecting login. An attacker who can enroll a new authenticator owns the account permanently. Lock enrollment paths behind re-authentication, require identity verification for new device registration, protect backup codes like passwords (store them hashed, never in plaintext), and alert on any enrollment change. Monitor for enrollment events outside business hours or from unfamiliar locations.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>Use step-up MFA rather than requiring a second factor on every single login. Trigger the additional challenge only when a session crosses a risk threshold \u2014 new device, unusual location, sensitive operation. Users tolerate security controls they barely notice; they route around ones that feel like friction.<\/em><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/csuxjmfbwmkxiegfpljm.supabase.co\/storage\/v1\/object\/public\/blog-images\/organization-6456\/1785003120612_Close-up-hands-enrolling-hardware-token-for-MFA.jpeg\" alt=\"Close-up hands enrolling hardware token for MFA\" title=\"\"><\/p>\n<hr>\n<h2 id=\"password-hygiene-passphrases-and-secure-credential-storage\"><span class=\"ez-toc-section\" id=\"Password_hygiene_passphrases_and_secure_credential_storage\"><\/span>Password hygiene, passphrases, and secure credential storage<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Prefer long passphrases and password managers over forced periodic rotation. <a href=\"https:\/\/pages.nist.gov\/800-63-3\/sp800-63b.html\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">NIST SP 800-63B<\/a> recommends a minimum of 15 characters and explicitly discourages mandatory rotation on a fixed schedule, because forced rotation drives predictable patterns (\u201cSummer2024!\u201d becomes \u201cFall2024!\u201d) without improving security.<\/p>\n<p><strong>Password policy: what to do and what to stop doing<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Do<\/th>\n<th>Stop Doing<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Require a minimum of 15 characters<\/td>\n<td>Mandating periodic rotation without a compromise trigger<\/td>\n<\/tr>\n<tr>\n<td>Accept passphrases and spaces<\/td>\n<td>Requiring special characters in specific positions<\/td>\n<\/tr>\n<tr>\n<td>Check against breached-credential lists<\/td>\n<td>Blocking users from pasting passwords<\/td>\n<\/tr>\n<tr>\n<td>Enforce uniqueness across your systems<\/td>\n<td>Capping maximum password length<\/td>\n<\/tr>\n<tr>\n<td>Trigger forced reset only after confirmed compromise<\/td>\n<td>Displaying password strength meters that reward complexity over length<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Migration checklist for legacy accounts:<\/strong><\/p>\n<ol>\n<li>Identify accounts still using passwords shorter than 15 characters via your IdP\u2019s reporting.<\/li>\n<li>Deploy breached-password detection and force resets for any account with a known-compromised credential.<\/li>\n<li>Communicate the new policy with a 30-day notice period and self-service reset tooling.<\/li>\n<li>Enable password manager autofill support on all login pages (no JavaScript that blocks paste).<\/li>\n<li>Phase out SMS recovery for high-risk accounts during the same window.<\/li>\n<\/ol>\n<p>For credential storage, use memory-hard hashing algorithms. Argon2id is the current recommendation; bcrypt and scrypt remain acceptable where Argon2id is not available. Set cost factors high enough that a single hash takes at least 100ms on your hardware, and plan to increase the cost factor as compute gets cheaper. Never store passwords with MD5, SHA-1, or unsalted SHA-256.<\/p>\n<p><strong>Pro Tip:<\/strong> <em>The master password for any password vault is a catastrophic single point of failure. Treat vault access as a privileged asset: require MFA on the vault itself, enforce device-level encryption, and set session timeouts that match your most sensitive system policies. A <a href=\"https:\/\/logmeonce.com\/blog\/password-management\/how-secure-are-password-manager-tools\" target=\"_blank\" rel=\"noopener\">well-secured password manager<\/a> with MFA is dramatically safer than the alternative.<\/em><\/p>\n<hr>\n<h2 id=\"how-to-secure-tokens-sessions-and-api-credentials\"><span class=\"ez-toc-section\" id=\"How_to_secure_tokens_sessions_and_API_credentials\"><\/span>How to secure tokens, sessions, and API credentials<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Tokens and sessions are high-value secrets. An attacker who captures a valid session token or API key does not need your password. The implementation details that prevent this are straightforward but frequently skipped under delivery pressure.<\/p>\n<p><strong>JWT and session hardening:<\/strong><\/p>\n<ul>\n<li>Validate the signature algorithm explicitly \u2014 reject tokens that specify <code>alg: none<\/code>.<\/li>\n<li>Verify all relevant claims: <code>iss<\/code>, <code>aud<\/code>, <code>exp<\/code>, and <code>nbf<\/code> at minimum.<\/li>\n<li>Set short expiry windows: 15 minutes for access tokens, longer for refresh tokens with rotation.<\/li>\n<li>Bind refresh tokens to device fingerprint or user context; invalidate them on logout and on suspicious activity.<\/li>\n<li>Implement token revocation lists or use short-lived tokens with a central introspection endpoint.<\/li>\n<li>Never store JWTs in <code>localStorage<\/code> \u2014 use <code>HttpOnly<\/code> cookies with <code>Secure<\/code> and <code>SameSite=Strict<\/code>.<\/li>\n<\/ul>\n<p><strong>Secret management for APIs and service accounts:<\/strong><\/p>\n<ul>\n<li>Remove every hardcoded secret from source code and configuration files. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) to inject credentials at runtime.<\/li>\n<li>Apply least privilege to every service account \u2014 scope API keys to the minimum permissions the service actually needs.<\/li>\n<li>Set short TTLs on API keys and rotate them automatically. Any key that cannot be rotated without a deployment is a liability.<\/li>\n<li>Enable usage monitoring on API keys and alert on anomalous call patterns (volume spikes, off-hours access, unexpected endpoints).<\/li>\n<\/ul>\n<p>Rate limiting is not optional. Apply it at the authentication endpoint, the token issuance endpoint, and any API that accepts credentials. Lockout or throttle after repeated failures, and use CAPTCHA or proof-of-work challenges for unauthenticated endpoints that show signs of automation.<\/p>\n<hr>\n<h2 id=\"transport-cookies-and-platform-hardening-for-authentication-flows\"><span class=\"ez-toc-section\" id=\"Transport_cookies_and_platform_hardening_for_authentication_flows\"><\/span>Transport, cookies, and platform hardening for authentication flows<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Always use strong TLS and correct cookie settings for every authentication endpoint. This is the shortest path between \u201cwe have a vulnerability\u201d and \u201cwe fixed it\u201d because most of these controls are configuration changes, not code changes.<\/p>\n<p><strong>Checklist:<\/strong><\/p>\n<ul>\n<li>Enforce HTTPS everywhere; redirect all HTTP traffic to HTTPS with a 301.<\/li>\n<li>Set HTTP Strict Transport Security (HSTS) with a <code>max-age<\/code> of at least one year and include <code>includeSubDomains<\/code>.<\/li>\n<li>Mark all session cookies <code>Secure<\/code>, <code>HttpOnly<\/code>, and <code>SameSite=Strict<\/code> (or <code>Lax<\/code> where cross-site flows require it).<\/li>\n<li>Implement CSRF tokens on all state-changing authentication endpoints.<\/li>\n<li>Set strict CORS policies \u2014 do not allow wildcard origins on endpoints that handle credentials.<\/li>\n<li>Use generic error messages on login pages (\u201cInvalid username or password\u201d) to prevent username enumeration.<\/li>\n<li>Pin certificates for mobile apps that handle authentication, and validate the full certificate chain.<\/li>\n<li>Keep all cryptographic libraries current; subscribe to CVE feeds for OpenSSL, BoringSSL, and any TLS library in your stack.<\/li>\n<\/ul>\n<p>On the XSS front: a single reflected XSS vulnerability on your login page can bypass every cookie flag you set, because the attacker runs code in the authenticated context. Content Security Policy headers are your primary mitigation. Set a strict CSP that blocks inline scripts and restricts script sources to your own domains.<\/p>\n<p>The <a href=\"https:\/\/www.cisa.gov\/topics\/cybersecurity-best-practices\/multifactor-authentication\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">CISA guidance on MFA<\/a> reinforces that transport security and phishing-resistant authentication work together \u2014 neither alone is sufficient for high-risk systems.<\/p>\n<hr>\n<h2 id=\"modern-options-adaptive-mfa-passwordless-and-fido2webauthn\"><span class=\"ez-toc-section\" id=\"Modern_options_adaptive_MFA_passwordless_and_FIDO2WebAuthn\"><\/span>Modern options: adaptive MFA, passwordless, and FIDO2\/WebAuthn<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Adopt FIDO2\/WebAuthn or adaptive MFA where feasible. These are not aspirational \u2014 they are deployable today for most enterprise and consumer use cases, and they close phishing vectors that TOTP-based MFA leaves open.<\/p>\n<p><strong>When each approach fits:<\/strong><\/p>\n<ul>\n<li><strong>Consumer passwordless (passkeys):<\/strong> Best for reducing friction on high-volume login flows. Passkeys are device-bound public-key credentials that <a href=\"https:\/\/www.nist.gov\/cybersecurity-and-privacy\/how-do-i-create-good-password\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">NIST recommends<\/a> as a safer alternative to passwords. Recovery complexity is the main challenge \u2014 design multi-step identity proofing for account recovery, not a fallback password.<\/li>\n<li><strong>Enterprise SSO + adaptive MFA:<\/strong> The right fit for most organizations today. Centralize authentication through your IdP, apply risk-based step-up challenges, and use hardware keys for admin roles. Adaptive authentication reduces friction while still enforcing stronger challenges for risky sessions.<\/li>\n<li><strong>High-value admin roles:<\/strong> Hardware FIDO2 keys only. No exceptions for accounts with production access, billing authority, or identity provider administration.<\/li>\n<\/ul>\n<p><strong>Tradeoff comparison:<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Approach<\/th>\n<th>Phishing resistance<\/th>\n<th>Recovery complexity<\/th>\n<th>Onboarding effort<\/th>\n<th>Device lifecycle risk<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Consumer passwordless (passkeys)<\/td>\n<td>High<\/td>\n<td>High<\/td>\n<td>Low<\/td>\n<td>Medium<\/td>\n<\/tr>\n<tr>\n<td>Enterprise SSO + adaptive MFA<\/td>\n<td>Medium\u2013High<\/td>\n<td>Medium<\/td>\n<td>Medium<\/td>\n<td>Low<\/td>\n<\/tr>\n<tr>\n<td>Legacy password + TOTP MFA<\/td>\n<td>Low<\/td>\n<td>Low<\/td>\n<td>Low<\/td>\n<td>Low<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>WebAuthn registration requires a relying party server that stores public keys (never private keys), a client-side credential creation flow, and a user verification step (PIN or biometric) that happens locally on the device. The private key never leaves the device. Recovery strategies must not recreate a weak secret \u2014 use escrowed device recovery or multi-step identity proofing as your fallback path, not a backup password.<\/p>\n<p>Biometrics in this context are a local unlock mechanism, not a standalone authenticator. The biometric unlocks the private key stored on the device; the cryptographic assertion is what authenticates to the server. That distinction matters for both security architecture and regulatory compliance.<\/p>\n<hr>\n<h2 id=\"how-to-roll-out-stronger-authentication-at-scale\"><span class=\"ez-toc-section\" id=\"How_to_roll_out_stronger_authentication_at_scale\"><\/span>How to roll out stronger authentication at scale<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Start with discovery: you cannot protect identities you have not inventoried. Map every authentication entry point, service account, and federated identity before you enforce anything.<\/p>\n<p><strong>Phased rollout:<\/strong><\/p>\n<ol>\n<li><strong>Discovery (Week 1\u20132):<\/strong> Inventory all applications, APIs, and service accounts. Identify authentication methods in use, MFA coverage gaps, and accounts with elevated privileges. Flag any hardcoded secrets.<\/li>\n<li><strong>Pilot (Week 3\u20134):<\/strong> Enforce new controls for a representative pilot group (IT staff, security team, one business unit). Measure helpdesk ticket volume, failed login rates, and user feedback.<\/li>\n<li><strong>Phased enforcement (Month 2\u20133):<\/strong> Roll out by risk tier \u2014 privileged accounts first, then finance and HR, then general workforce. Communicate each wave two weeks in advance.<\/li>\n<li><strong>Monitoring and iteration (Month 3+):<\/strong> Track MFA adoption rate, failed login trends, helpdesk volume, and time-to-recover after lockouts. Adjust enforcement thresholds based on telemetry.<\/li>\n<\/ol>\n<p><strong>Rollback criteria:<\/strong> If helpdesk volume exceeds 3x baseline during any enforcement wave, pause and investigate before continuing. Have a documented rollback path for every enforcement change.<\/p>\n<p><strong>Metrics to track:<\/strong><\/p>\n<ul>\n<li>MFA adoption rate by user segment (target: 100% for privileged, 95%+ for general workforce)<\/li>\n<li>Failed login attempts per hour (baseline, then trend)<\/li>\n<li>Helpdesk ticket volume for authentication issues<\/li>\n<li>Number of credentials appearing in breach databases<\/li>\n<li>Time-to-recover after account lockout<\/li>\n<\/ul>\n<p><strong>Communication template bullets:<\/strong><\/p>\n<ul>\n<li>User email: \u201cStarting [date], you will need to verify your identity with a second factor when logging into [system]. Here is how to set it up in under two minutes: [link].\u201d<\/li>\n<li>Admin notification: \u201cEnforcement begins [date]. Accounts without MFA enrolled will be blocked. Exceptions require manager approval via [process].\u201d<\/li>\n<li>Helpdesk script: \u201cIf a user is locked out after MFA enforcement, verify identity via [approved method], then use the admin console to grant a 24-hour bypass while they re-enroll.\u201d<\/li>\n<\/ul>\n<p>For enterprise rollouts, <a href=\"https:\/\/logmeonce.com\/enterprise-password-management-1\" target=\"_blank\" rel=\"noopener\">enterprise password management guidance<\/a> covers vault deployment, secure sharing, and the operational controls that prevent team vaults from creating new failure modes.<\/p>\n<hr>\n<h2 id=\"monitoring-detection-and-incident-response-for-authentication-events\"><span class=\"ez-toc-section\" id=\"Monitoring_detection_and_incident_response_for_authentication_events\"><\/span>Monitoring, detection, and incident response for authentication events<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Design authentication logging to detect account takeover early. The log fields you capture determine what you can investigate after an incident \u2014 and most teams log too little.<\/p>\n<p><strong>Essential log fields:<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Field<\/th>\n<th>Purpose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Timestamp (UTC)<\/td>\n<td>Correlation across systems<\/td>\n<\/tr>\n<tr>\n<td>Source IP and ASN<\/td>\n<td>Geolocation, impossible travel detection<\/td>\n<\/tr>\n<tr>\n<td>Device fingerprint<\/td>\n<td>Detect new or anomalous devices<\/td>\n<\/tr>\n<tr>\n<td>Authentication factor used<\/td>\n<td>Identify MFA bypass events<\/td>\n<\/tr>\n<tr>\n<td>Risk score (if available)<\/td>\n<td>Adaptive policy decisions<\/td>\n<\/tr>\n<tr>\n<td>Outcome (success\/failure\/challenge)<\/td>\n<td>Failure rate trending<\/td>\n<\/tr>\n<tr>\n<td>User agent<\/td>\n<td>Bot detection<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Retain authentication logs for at least 90 days for investigations, 12 months for compliance. Store them in a SIEM or log management system that is separate from the systems being monitored.<\/p>\n<p><strong>Detection rules to implement:<\/strong><\/p>\n<ul>\n<li>Impossible travel: successful logins from two geographically distant IPs within a time window that makes physical travel impossible.<\/li>\n<li>Repeated failures: more than 5 failed attempts within 10 minutes for a single account.<\/li>\n<li>Enrollment changes: any new authenticator registered outside business hours or from an unrecognized device.<\/li>\n<li>MFA bypass events: successful logins without a second factor for accounts where MFA is required.<\/li>\n<li>Anomalous token use: API keys used from new IPs, at unusual hours, or at volumes far above baseline.<\/li>\n<\/ul>\n<p><strong>Incident response checklist:<\/strong><\/p>\n<ol>\n<li>Immediately revoke active sessions and tokens for the compromised account.<\/li>\n<li>Force a password reset and re-enrollment of MFA factors.<\/li>\n<li>Rotate any API keys or service account credentials the account had access to.<\/li>\n<li>Preserve logs before any remediation that might overwrite them.<\/li>\n<li>Notify the affected user through an out-of-band channel (phone, not email, if email is compromised).<\/li>\n<li>Conduct a post-incident review within 72 hours and update runbooks with any gaps discovered.<\/li>\n<\/ol>\n<p>Authentication incidents that go undetected for more than 24 hours dramatically increase the blast radius. Early detection is the control that limits damage when prevention fails.<\/p>\n<hr>\n<h2 id=\"common-authentication-problems-and-how-to-fix-them\"><span class=\"ez-toc-section\" id=\"Common_authentication_problems_and_how_to_fix_them\"><\/span>Common authentication problems and how to fix them<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The most common failure modes have known fixes. The problem is usually that teams discover them under pressure, without a runbook.<\/p>\n<p><strong>Failure modes and one-line fixes:<\/strong><\/p>\n<ul>\n<li><strong>Users locked out after policy enforcement:<\/strong> Stage enforcement with a 48-hour grace period and send proactive setup instructions before the deadline.<\/li>\n<li><strong>Broken SSO attribute mappings:<\/strong> Validate SAML\/OIDC attribute mappings in a staging environment before any IdP configuration change goes to production.<\/li>\n<li><strong>Expired TLS certificates:<\/strong> Automate certificate renewal with Let\u2019s Encrypt or your CA\u2019s ACME client; alert 30 days before expiry.<\/li>\n<li><strong>JWT signature failures:<\/strong> Confirm the signing algorithm and key ID match between the issuer and the verifier; check for clock skew exceeding the <code>nbf<\/code>\/<code>exp<\/code> tolerance.<\/li>\n<li><strong>Refresh token misuse:<\/strong> Implement refresh token rotation \u2014 invalidate the old token the moment a new one is issued, and treat reuse of an invalidated refresh token as a compromise signal.<\/li>\n<li><strong>MFA enrollment failures:<\/strong> Provide a fallback enrollment path (QR code plus manual key entry) and test it on every supported device type before rollout.<\/li>\n<li><strong>Lost authenticators:<\/strong> Require identity verification (government ID or manager attestation) before issuing a recovery code; never bypass MFA with only a password.<\/li>\n<\/ul>\n<p><strong>Quick fixes for suspected compromise:<\/strong><\/p>\n<ul>\n<li>Immediately revoke all active sessions via your IdP\u2019s admin console.<\/li>\n<li>Issue a temporary admin override only through a documented, audited process \u2014 never verbally.<\/li>\n<li>Use safe rollback: revert to the last known-good authentication configuration, not to a weaker baseline.<\/li>\n<\/ul>\n<p>After any authentication incident, run a postmortem within 72 hours. Update your runbook with the specific failure mode, the detection gap, and the fix. Repeat incidents are a runbook failure, not a user failure.<\/p>\n<hr>\n<h2 id=\"standards-and-evidence-that-validate-these-recommendations\"><span class=\"ez-toc-section\" id=\"Standards_and_evidence_that_validate_these_recommendations\"><\/span>Standards and evidence that validate these recommendations<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>NIST SP 800-63B\u2019s Authentication Assurance Levels give implementers a direct mapping from risk to control. AAL1 covers single-factor or MFA with a wide range of authenticator types. AAL2 requires phishing-resistant options. AAL3 requires non-exportable keys and public-key cryptography \u2014 in practice, hardware FIDO2 keys. If you are protecting privileged access or regulated data, AAL2 is your floor and AAL3 is your target for the highest-risk roles.<\/p>\n<p>OWASP\u2019s Authentication Cheat Sheet reinforces several controls covered here: use of authenticator apps or hardware tokens over SMS for high-value accounts, hardening of recovery paths, and protection of backup codes. The OWASP guidance also specifies that login failure messages must not reveal whether the username or password was incorrect \u2014 a detail that prevents username enumeration at scale.<\/p>\n<p>For auditors and procurement reviewers, the evidence package should include:<\/p>\n<ul>\n<li>Documented enrollment policies with re-authentication requirements.<\/li>\n<li>Key rotation logs showing automated rotation cadence for service accounts.<\/li>\n<li>Authentication event logs with retention timestamps.<\/li>\n<li>MFA adoption rate reports by user segment.<\/li>\n<li>A written incident response plan that references authentication-specific playbooks.<\/li>\n<\/ul>\n<p>NIST SP 800-63-4 adds requirements around anti-fraud measures for enrollment processes and explicitly addresses phishing-resistant authentication options \u2014 both directly relevant to the controls in this guide.<\/p>\n<hr>\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, secure credential storage, and continuous authentication monitoring are the three controls that deliver the greatest risk reduction per unit of implementation effort.<\/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>Enforce phishing-resistant MFA first<\/td>\n<td>Hardware FIDO2 keys or passkeys for privileged roles; any MFA for general workforce beats none.<\/td>\n<\/tr>\n<tr>\n<td>Replace rotation policies with breach detection<\/td>\n<td>NIST recommends 15+ character passphrases and triggered resets after compromise, not fixed schedules.<\/td>\n<\/tr>\n<tr>\n<td>Treat tokens and secrets as credentials<\/td>\n<td>Short-lived JWTs, refresh token rotation, and vault-managed API keys prevent persistent compromise.<\/td>\n<\/tr>\n<tr>\n<td>Log and alert on authentication events<\/td>\n<td>Capture IP, device, factor used, and outcome; alert on impossible travel and enrollment changes.<\/td>\n<\/tr>\n<tr>\n<td>Logmeonce for integrated rollout<\/td>\n<td>Logmeonce combines MFA, SSO, password vaulting, and dark web monitoring in one platform for faster deployment.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<hr>\n<h2 id=\"the-first-90-days-a-security-leaders-honest-priorities\"><span class=\"ez-toc-section\" id=\"The_first_90_days_a_security_leaders_honest_priorities\"><\/span>The first 90 days: a security leader\u2019s honest priorities<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The single best 90-day priority is protecting privileged identities before anything else. Admin accounts, cloud consoles, and email are where attackers pivot from a single compromised credential to full organizational access. Everything else can wait two weeks.<\/p>\n<p><strong>Month 1 \u2014 discovery and quick wins:<\/strong><\/p>\n<ul>\n<li>Complete an identity inventory: every admin account, service account, and federated identity.<\/li>\n<li>Enforce MFA on all privileged accounts. No exceptions, no grace extensions beyond 72 hours.<\/li>\n<li>Scan for hardcoded secrets in source code and CI\/CD pipelines. Rotate anything found immediately.<\/li>\n<li>Enable breached-password detection on your IdP.<\/li>\n<\/ul>\n<p><strong>Month 2 \u2014 pilot and phased enforcement:<\/strong><\/p>\n<ul>\n<li>Roll out the new password policy (15+ characters, no forced rotation) to a pilot group.<\/li>\n<li>Begin enforcing MFA for finance, HR, and code repositories.<\/li>\n<li>Stand up authentication event logging in your SIEM with the detection rules from Section 9.<\/li>\n<li>Run a tabletop exercise on an authentication incident scenario.<\/li>\n<\/ul>\n<p><strong>Month 3 \u2014 measurement and iteration:<\/strong><\/p>\n<ul>\n<li>Report MFA adoption rate to leadership. If it is below 90% for general workforce, investigate the blockers.<\/li>\n<li>Review helpdesk ticket volume for authentication issues. Anything above 5% of your user base per month signals a UX problem, not a security problem.<\/li>\n<li>Update runbooks based on any incidents or near-misses from the pilot period.<\/li>\n<li>Plan the passwordless migration roadmap for consumer-facing flows.<\/li>\n<\/ul>\n<p>The tradeoffs are real. Helpdesk volume will spike during enforcement waves \u2014 budget for it. Users will push back on hardware keys until they lose an account to phishing, at which point they become advocates. The friction is front-loaded; the security gain is permanent. Protect admin consoles and email first, because those two systems are the keys to everything else in your environment.<\/p>\n<hr>\n<h2 id=\"logmeonce-accelerates-authentication-security-for-security-teams\"><span class=\"ez-toc-section\" id=\"Logmeonce_accelerates_authentication_security_for_security_teams\"><\/span>Logmeonce accelerates authentication security for security teams<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Security teams evaluating authentication platforms face a real build-vs-buy decision. Building MFA enrollment, vault management, SSO integration, and breach monitoring from scratch takes months and requires ongoing maintenance. The case for a platform gets stronger as the number of applications, user segments, and compliance requirements grows.<\/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 brings together <a href=\"https:\/\/logmeonce.com\/cybersecurity\" target=\"_blank\" rel=\"noopener\">MFA, SSO, password vaulting<\/a>, dark web monitoring, and cloud encryption in a single platform designed for organizations that need to move fast without cutting corners. For security teams working through the rollout plan in this guide, that means shorter time-to-secure on the controls that matter most: phishing-resistant authentication, centralized credential management, and continuous breach monitoring.<\/p>\n<p>When evaluating any authentication platform, check for these capabilities:<\/p>\n<ul>\n<li>Phishing-resistant MFA options (FIDO2\/WebAuthn support)<\/li>\n<li>SSO with SAML and OIDC for broad application coverage<\/li>\n<li>End-to-end encrypted credential vaulting with secure sharing<\/li>\n<li>Automated breach monitoring and credential exposure alerts<\/li>\n<li>Authentication event telemetry and SIEM integration<\/li>\n<li>Documented recovery controls and enrollment protections<\/li>\n<\/ul>\n<p>Logmeonce covers each of these. Security teams can start with a free trial to evaluate the platform against their specific environment before committing to a full rollout.<\/p>\n<hr>\n<h2 id=\"useful-sources-for-further-reading\"><span class=\"ez-toc-section\" id=\"Useful_sources_for_further_reading\"><\/span>Useful sources for further reading<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The resources below are the primary references for the controls and standards in this guide. Use them for policy drafting, audit evidence, and procurement documentation.<\/p>\n<ul>\n<li><strong>NIST SP 800-63B: Authentication and Authenticator Management<\/strong> \u2014 The definitive standard for authentication assurance levels, authenticator types, and password policy. Use this for policy drafting and auditor conversations.<\/li>\n<li><strong>NIST SP 800-63-4: Digital Identity Guidelines<\/strong> \u2014 The updated framework covering identity proofing, federation, and anti-fraud controls. Use this for risk assessment and assurance level selection.<\/li>\n<li><strong>NIST Password Guidance<\/strong> \u2014 Practical guidance on passphrases, password managers, and passkeys. Use this for user-facing policy communication.<\/li>\n<li><strong>OWASP Authentication Cheat Sheet<\/strong> \u2014 Implementation-level guidance on MFA, session management, error messages, and credential storage. Use this for developer and engineering teams.<\/li>\n<li><strong>CISA: Multifactor Authentication<\/strong> \u2014 Federal guidance on MFA adoption and phishing-resistant options. Use this for compliance and government-adjacent procurement.<\/li>\n<li><strong>NCSC: Choosing Authentication Methods<\/strong> \u2014 Practical comparison of MFA, FIDO2, magic links, and federated SSO for customer-facing services. Useful for authentication methods comparison across different user populations.<\/li>\n<li><strong>Logmeonce Resources<\/strong> \u2014 Educational content, implementation guides, and product documentation for organizations evaluating enterprise password management and MFA platforms.<\/li>\n<li><strong>Logmeonce Enterprise Password Management<\/strong> \u2014 Product documentation covering vault deployment, SSO, and enterprise rollout considerations.<\/li>\n<\/ul>\n<hr>\n<h2 id=\"the-part-most-guides-skip-recovery-is-where-authentication-actually-fails\"><span class=\"ez-toc-section\" id=\"The_part_most_guides_skip_recovery_is_where_authentication_actually_fails\"><\/span>The part most guides skip: recovery is where authentication actually fails<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Most authentication security guides spend 90% of their words on the login flow and about two paragraphs on recovery. That is backwards. Recovery is where attackers focus once you harden the front door.<\/p>\n<p>The uncomfortable reality is that every recovery mechanism you build is a potential bypass for every control you just implemented. A \u201cforgot password\u201d flow that sends a reset link to an email account the attacker already controls defeats your MFA entirely. A helpdesk that resets MFA after a phone call and a name verification defeats your hardware key requirement. A backup code stored in a notes app defeats your vault.<\/p>\n<p>The organizations that get this right treat recovery as a separate threat model, not an afterthought. They require out-of-band identity verification for account recovery \u2014 not just \u201canswer your security question\u201d or \u201cwe\u2019ll send you an email.\u201d They audit recovery events the same way they audit privileged access. They test recovery flows in red team exercises specifically because those flows are where the gaps hide.<\/p>\n<p>Passwordless authentication makes this harder, not easier. When there is no password to reset, recovery requires proving identity through other means \u2014 and those means have to be strong enough to not recreate the original weakness. Multi-step identity proofing, escrowed device recovery, and manager attestation are the patterns that work. A fallback password is not a recovery mechanism; it is a second attack surface.<\/p>\n<p>The 90-day plan in this guide will get your authentication controls to a defensible state. The work that keeps them there is continuous: reviewing recovery flows, auditing enrollment events, and running tabletop exercises on the scenarios your detection rules are not yet catching.<\/p>\n\n<div style=\"font-size: 0px; height: 0px; line-height: 0px; margin: 0; padding: 0; clear: both;\"><\/div>","protected":false},"excerpt":{"rendered":"<p>Discover how to improve authentication security with essential MFA tips, TLS enforcement, and tips to block high-risk attacks. Act now!<\/p>\n","protected":false},"author":0,"featured_media":248181,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-248179","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\/248179","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=248179"}],"version-history":[{"count":1,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts\/248179\/revisions"}],"predecessor-version":[{"id":248180,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/posts\/248179\/revisions\/248180"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/media\/248181"}],"wp:attachment":[{"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/media?parent=248179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/categories?post=248179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/logmeonce.com\/resources\/wp-json\/wp\/v2\/tags?post=248179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}