MFA Fatigue on VPN and Contractor Over-Access

Assessment: the pattern is textbook MFA fatigue - repeated prompts until the user approves out of irritation. An approved push means the attacker likely holds valid credentials, so this is a credential-compromise incident, not just an MFA tuning issue.

Immediate:

1. Treat the approved push as a compromise: reset credentials for that user, revoke sessions/refresh tokens, review that user's VPN and application logs for post-auth activity, and check for newly registered MFA devices.
2. Force a re-authentication for the other five users and check for anomalies.
3. Rate-limit or temporarily block Duo push for the affected accounts.

Structural:

• Move Duo policy to verified push / number matching for the VPN application - the user must type a code shown on the login screen, which defeats blind approval. It is the single highest-value control here.
• Restrict push to known context: require managed device (Duo device trust) and, where feasible, restrict to expected geographies or networks.
• Prompt throttling and fraud reporting: limit prompts per user per interval and route reported fraud automatically to the SOC.
• Offer TOTP/WebAuthn as falling back options where push is inappropriate (contractors).

Note the help-desk ticket spike may itself be users who cannot get in - tune messaging so a legitimate user has a clear path.

Decision: remove the full-tunnel contractor profile. A full tunnel to contractor-owned devices grants network-level reach to everything the tunnel's ACL allows, and it is the wrong abstraction for 'four named web applications'.

Design:

• Replace the full tunnel with an application-scoped access path: either a clientless/reverse-proxy style portal or a ZTNA-style per-application access broker, publishing only the four applications. Authorization is per-app, per-user (AD group per application), not per-subnet.
• If AnyConnect must remain, use a split-tunnel profile with an ACL limited to the four application IPs/ports, deny-all else, and a separate IP pool so contractors never share address space with employees.
• Identity: require verified push (or TOTP) for contractors, add device trust posture at the identity layer instead of an endpoint agent on a device you do not own, and set session timeouts shorter than employee sessions.
• Authorize in ISE: put contractors in their own policy set keyed on the connection profile / certificate, returning a distinct authorization profile - do not differentiate by AD group alone, since group membership is easy to misassign.

Verify: test with a contractor account, attempt access to an in-scope-adjacent internal subnet, and confirm the deny is explicit and logged.

Yes, but sequenced. Monitor-only on 400 macOS endpoints means you are collecting compliance data and doing nothing with it - the data exists, so the question is only whether enforcement would break the user population.

Sequence:

1. Read the monitor data first. What percentage of the 400 currently fail (no disk encryption, outdated OS, missing agent)? If 30-40% fail, flipping to enforce generates a mass help-desk event, which is the worst outcome. If 3% fail, enforce now for those conditions only.
2. Enforce per-condition, not all-or-nothing: start with disk encryption and OS patch level (high value, low ambiguity), keep weaker conditions in monitor. Each condition you enforce needs a documented remediation flow, not a deny.
3. Remediate, don't block: send non-compliant macOS users to a remediation portal/VLAN with the fix instructions and a self-service path, so the help desk is not the first line.
4. Communicate before enabling, with a two-week notice and a grace period.

On the help-desk spike: separate the causes before changing policy - distinguish (a) users hitting the new MFA behavior, (b) genuinely non-compliant endpoints surfacing as posture becomes visible, and (c) a capacity or ISE node problem. If both ISE nodes are handling all RADIUS and one is degraded, VPN tickets spike for reasons unrelated to posture; check node health and RADIUS latency before concluding the policy is at fault.