FortiSASE Rollout: Egress Location, Inspection Gaps, and Unmanaged Contractors

The latency and the legal constraint are not actually in conflict - the conflict is between one global egress policy and a regional user base.

• Split the user population by data sensitivity, not by geography alone. EU staff working on EU client matters stay on EU PoPs with full tunnel, because their data must not egress elsewhere. Singapore staff working on Singapore or non-EU matters egress locally.
• Do not brute-force a global 'nearest PoP' policy. Nearest-PoP is a latency optimisation and knows nothing about data residency. Implement it as a policy layer on top of a residency rule: for users and applications tagged EU-restricted, the PoP is fixed; for everything else, nearest PoP wins.
• Application steering via split tunnel for trusted SaaS. Microsoft 365 is a sanctioned, well-identified application; steering it direct or to a local PoP removes the 210-260 ms round trip through Europe. Keep inspection at the endpoint for the managed fleet, since you lose inline visibility on the direct path - that trade must be explicit.
• Address the Dropbox behaviour directly. Users did not choose Dropbox because they like it; they chose it because the sanctioned path was slow. Fix the speed and simultaneously block or CASB-alert on personal Dropbox, or you will keep enforcing a policy users have already routed around.
• Validate before the five-week deadline. Run the Singapore office as a pilot for two weeks and measure to M365, to the matter-management portal, and to the EU-hosted document repository separately, because they will not behave the same.

Document the residency matrix and get legal to sign it - the technical split is worthless if the policy owner has not agreed which application holds which data class.

The finding is real but the prior fix was a category-level amputation. Solve it at the right granularity.

• Inspect by default on managed devices for the finance and banking category, and re-enable it. That is what the auditor is asking for and there is no technical reason to exempt the whole category.
• Carve the exception at the application level, not the category level. Identify the broker's specific destinations and certificate-pinned behaviour, exempt only those, and attach an expiry date and an owner. Category-wide exemptions age into permanent blind spots; destination-level exemptions can be reviewed.
• Do not inspect on unmanaged BYOD. Installing a root CA on a contractor's personal device is a privacy and legal problem in most jurisdictions and will not survive HR or works council review. Use a different control there: restrict the contractor to three known applications, so the inspection gap is bounded by a very small allow-list rather than being open internet access.
• Add compensating controls where inspection is impossible: CASB API-based scanning of sanctioned SaaS, DLP on egress for the document repository, and blocking of unsanctioned storage services so the uninspected path cannot become an exfiltration route.
• Test the broker exception before the month-end peak, not during it. Pinned applications tend to break at the worst moment, and an exception added under pressure is an exception nobody reviews.

Expect to explain a residual risk to the auditor: certificate-pinned applications are inspected at the endpoint, not inline, and here is the compensating control set.

Partially - and being honest about the boundary is the professional answer here.

What works without an agent:

• Zero-trust application access for the three sanctioned apps, scoped per application rather than per network, so a contractor authenticated to the matter-management portal cannot reach anything else on that network segment.
• Identity-centric policy: contractor identity provider group, device-agnostic, with step-up authentication and session timeouts appropriate for a population that is not on your hardware.
• Clientless access for web-delivered applications where the tenant supports it. For the browser-rendered portal and e-billing tool this is usually achievable; for a thick-client or heavily conditional-access-bound application it may not be.
• Restrict, log, and rate-limit every contractor session, and alert on attempts to reach anything outside the three-app allow-list - those attempts are your best detection signal for a compromised contractor account.

Where the constraint genuinely bites:

• No device posture. Without an agent you cannot assert patch level, disk encryption, screen lock, or the presence of malware. That is an accepted risk, not a solved one. Say so in writing.
• DLP on the endpoint is unavailable. Contractor downloads of client matter documents can be logged but not blocked at the device.
• If the e-billing tool requires a thick client or a pinned certificate chain, agentless access may not be deliverable for that one app. If so, the real options are a managed VDI workspace for contractors or a renegotiation of the HR constraint.

Recommend: agentless ZTNA for the two browser apps, a brokered virtual desktop for the third if required, and a documented residual-risk acceptance for device posture.