Episode 35 — Safeguard 7.3 – Integration with patch management
Welcome to Episode 35, Control 6 — Authentication Factors and Session Rules, where we set anchor goals for strong authentication across real workplaces. The objective is simple to say and tricky to do: confirm who is acting, confirm the device they use, and contain the time window in which that action is valid. We want predictable rules that hold up on busy Mondays and during incident response at two in the morning. Our goals include reducing takeover risk, shrinking the blast radius if a token leaks, and making reviews easy to prove. We also aim to favor methods that resist common tricks like fake login pages and consent spam. Finally, we want repeatable enrollment, safe recovery, and clear session limits that reflect risk. When these goals align, authentication becomes a quiet guardrail rather than a daily obstacle.
Password settings still matter, but they must be tuned to reduce risk without creating workarounds. Favor longer passphrases over short complex strings, because length improves resistance while staying memorable. Ban the most common and previously breached passwords outright, using an updated deny list. Require unique credentials per system where federation is not available, and monitor reuse. Avoid frequent forced resets, which drive predictable patterns, and instead trigger resets on risk signals or confirmed compromise. Add rate limiting and progressive delays on failures to blunt automated guessing. Store hashes with modern, memory hard functions. Explain the “why” behind these settings to users, because their understanding improves adherence more than any banner can.
Multi factor authentication adds a second proof that attackers must defeat. The main methods fall into three groups: something you have, something you are, and something you know. Hardware security keys and platform authenticators provide strong possession factors with low fatigue. App based prompts are common and convenient, but they require safe prompt handling to avoid push bombing abuse. One time codes by text message remain widely supported, yet they carry higher risk from swap fraud and forwarding. Biometrics raise usability and are strong when backed by secure device hardware. Choose two or more methods that fit user roles and operating environments. Make the defaults easy for most people, while keeping stronger options ready for high risk groups.
Prefer phishing resistant authenticators whenever possible, because they remove whole classes of failure. Modern hardware keys, and platform authenticators bound to the browser, verify the website before they respond. They do not reveal reusable secrets, and they stop code relay and fake login portals. They also streamline sign in for users after the first setup, which helps adoption over time. Where full coverage is not yet realistic, start with administrators, remote staff, and users who handle regulated data. Pair these keys with policy that disables less secure fallbacks after a defined transition period. Track coverage as a primary metric, because this is the upgrade that moves risk curves the most. Plan spares and recovery to avoid lockouts during travel or device loss.
Enrollment, binding, and recovery steps determine whether strong factors hold up under stress. Enrollment must verify identity at the start, link a factor to the right person, and record the event. Binding should tie the factor to a managed device or a secure profile where possible. Recovery is the hardest part, because it is the path attackers target. Use in person checks, manager attestations, or help desk workflows with secondary evidence, and log each step. Limit the number of active recovery methods, and rotate fresh factors after recovery completes. Provide users two approved authenticators so one loss does not pause work. Practice the process during normal hours to learn where it breaks.
Device trust and managed posture checks connect identity to the state of the hardware. A known user on an unknown, unpatched, or jailbroken device is higher risk. Use device certificates, management enrollment, and health signals like disk encryption, screen lock, and current patches. Gate access to sensitive apps on posture, not only on identity. If posture fails, fall back to a reduced experience or require a remote browser that isolates risk. Keep the posture rules short, clear, and testable across platforms. Remember that contractors and partners may bring devices you do not manage; design a safe path that still honors business needs. Publish a one page checklist so users can self correct common posture failures.
Step up prompts for sensitive actions add authentication only when it matters most. Examples include viewing payroll records, exporting large data sets, or changing a security setting. A step up can be a fresh factor, a hardware key touch, or a manager approval routed through a workflow. Tie prompts to risk signals such as unusual location, new device, or high value transactions. Keep the prompt frequency low enough to avoid fatigue, but firm enough to catch misuse. Record the reason for each step up in the audit trail. This approach limits friction for daily tasks while adding strong checks at the moments of greatest consequence.
Session lifetimes and idle timeouts keep access from lasting longer than needed. Shorter sessions reduce the chance that a hijacked cookie grants long standing entry. Idle timeouts protect against unattended screens and borrowed laptops. For general user portals, daily sessions with modest idle limits often work well. For administrative consoles, prefer much shorter windows with mandatory reapproval. Tie session refresh to posture and network changes so that movement from a safe to unsafe context forces a check. Communicate the rule to users in plain words on the sign in page, so surprises do not look like errors. Log session creation, refresh, and termination for later review.
Reauthentication windows by risk level make your model adaptive. A person reading internal announcements should reauthenticate far less often than a person editing production settings. Group applications into tiers and assign windows for each tier. For example, read only portals may renew once per day, finance approvals may renew every few hours, and root level tasks may require a fresh factor for each critical action. Apply stricter windows when the user crosses a boundary such as leaving the corporate network or switching devices. Keep a table of tiers in your documentation so developers and admins can align new apps without guesswork. Review these windows twice a year as threats and workflows evolve.
Remote access and single sign on must work together without creating a single brittle point. Use modern tunnels or zero trust access brokers that verify user, device, and context per request. Feed posture, group membership, and time of day into policy decisions. Single sign on should front as many applications as possible, because central rules are easier to enforce and audit. Protect the identity provider with the strongest factors you have, and consider hardware keys as the default there. For legacy systems that cannot federate, place them behind an access broker or a reverse proxy that can enforce policy on their behalf. Keep emergency bypass plans documented and tested.
Legacy protocols and exception handling require caution, not denial by slogan. Some systems still depend on outdated mail or file protocols that do not support modern factors. Start by isolating them on dedicated paths with tight network rules and strong monitoring. Require compensating controls like jump hosts, read only access, or time bound windows. Document each exception with an owner, a business reason, and a retirement date. Track the count of these exceptions as a visible metric. Work toward upgrades on a schedule, and remove the exception the week the upgrade lands. Do not allow silent renewal; force a fresh approval each cycle.
Monitoring failures and lockout responses turn signals into action. Track failed logins, push fatigues, repeated code entries, and step up declines. Correlate by user, device, location, and app to spot patterns. Use progressive delays and account lockouts with care, because attackers may try to cause denial of service. Provide users a clear path to recover when they lock themselves out, and verify identity strongly during recovery. Alert on impossible travel events and on bursts of second factor prompts. Feed all of this to a central monitoring platform so incident responders see the full picture quickly. Close the loop with periodic reviews of noisy rules.
Evidence examples and verification procedures must be easy to reproduce. Reviewers accept exports from the identity provider showing factor enrollment, screenshots of policy pages with version and date, and logs proving session durations. They will ask for samples of step up events, records of recovery approvals, and proof that legacy exceptions were renewed or retired on time. Maintain a simple run book that shows how to regenerate each artifact with a few clicks or a single query. Keep timestamps, environment labels, and approver names visible. Store evidence in a read only location, and tag it by month and system to speed audits.
Strong authentication succeeds when deployment sequencing respects people and risk. Start with identity provider protection, because it guards every downstream app. Move next to administrators, remote users, and data owners, because their compromise hurts most. Roll out phishing resistant keys to those groups first, then expand as hardware and support mature. Introduce step up prompts in high value workflows, and set conservative session rules for admin consoles. Phase posture checks with clear guides and help desk scripts. Close by tuning legacy paths and retiring exceptions. End with a short message that reminds teams the goal is simple: keep access honest, short lived, and provably strong.
