VPN egress added to trusted zone weakens MFA for contractors
A financial services firm has 800 contractors and 1,200 employees. Okta global session policy requires MFA for everyone, but an app sign-on policy for LedgerPro exempts users in the Corporate Network zone from MFA. The zone contains the four office egress ranges. During a cloud migration, 300 contractors began connecting through a VPN whose NAT egress is 198.51.100.0/24. To reduce helpdesk tickets, an admin added that /24 to the Corporate Network zone. Two weeks later, the security team sees 19 Okta Verify push prompts approved from a single contractor laptop in 40 minutes, and one ledger export from an unusual location. Contractors also report being prompted twice: once at Okta and once inside LedgerPro. The firm has Okta Verify with number challenge and FIDO2 keys, but not all contractors have FIDO2.
1. Evaluate the decision to add the VPN egress range to the trusted zone. What is the security impact, and what alternatives would you propose?
Read the worked answer
Adding the VPN range to Corporate Network made every user on that VPN eligible for the MFA exemption, not just the contractors who needed relief. Network zones are IP-based, so they cannot tell a managed laptop from a compromised one, and a shared NAT range hides individual user behavior. The result is a weaker authentication path for LedgerPro and a plausible push-fatigue incident. I would remove the VPN range from the trusted zone and create a separate Contractor VPN zone if network context is still useful. Then I would use a dedicated app sign-on policy that still requires MFA but reduces prompts through session lifetime and device trust. For managed devices, Okta FastPass can provide phishing-resistant, device-bound authentication. High-risk actions such as ledger export should require step-up authentication with a number challenge or FIDO2, regardless of network.
2. How would you redesign the sign-on policy for LedgerPro to reduce prompts without weakening authentication?
Read the worked answer
Start with a global session policy that requires MFA at sign-in and sets a reasonable session lifetime. For LedgerPro, use an app sign-on policy that requires MFA once per session rather than on every app launch, and separate employees from contractors by group. For managed contractor laptops, require device trust and prefer FastPass or FIDO2; for unmanaged devices, keep Okta Verify with number challenge. Add a risk-based rule for unusual location or new device that forces re-authentication. Do not exempt a shared VPN range. The double prompt is a separate issue: if LedgerPro has its own MFA, coordinate with the vendor rather than adding a second Okta prompt. The goal is to reduce unnecessary prompts while keeping a strong factor for the app and for sensitive actions.
3. What signals would you use to triage the 19 push approvals and the export?
Read the worked answer
I would correlate Okta System Log events for authentication, MFA, and app access with the contractor's device and network context. Look at the timestamps of the 19 push approvals, the IP addresses, user agent, device trust status, and whether the prompts followed a new sign-in or an existing session. For the export, check the LedgerPro sign-on event, the user's group membership, and whether the export happened after a step-up or from an unusual location. I would compare the IP with the VPN range and with the contractor's normal behavior, but I would not assume the VPN explains the anomaly. If compromise is plausible, revoke the user's sessions and tokens, reset factors, and review recent policy or group changes. The judgement is to contain first, then determine whether the MFA exemption or a stolen session enabled the activity.