HTTPS Inspection and MS/Office365, once more

[David_C1]

Hi everyone,

Curious, here in early 2026, what people are implementing for inspection/bypass for access to Office365 (SharePoint, Teams, Outlook, etc). Back when we first implemented HTTPS Inspection, we ended up putting in a number of bypass rules for various MS/Office365 services. I'm trying to clean this up - ideally we'd inspect - having DPI for files moving back and forth between OneDrive would be ideal from a Threat Prevention perspective, and many Applications Signatures say they require HTTPS Inspection for application detection (e.g. Microsoft Teams). On the other hand...if it ain't broke, don't mess with it. So I'm looking for what other people have currently in place and how that is working for you and your users.

Thanks,

Dave

[PhoneBoy]

You might not need to do DPI on Office 365 traffic if you're using Email and Collaboration, since some security functions can be done as part of that product. 

[the_rock]

I will tell you what I do in the lab, but Im sure this is NOT something many people would ever do. I use wildcards and literally exempt anything *outlook* *teams* and *microsoft*. Otherwise, you may find yourself troubleshooting this for hours on end trying to figure out what needs to be allowed/exempted.

[David_C1]

Andy and PhoneBoy,

Appreciate the responses. FWIW we do use some MS native tools for threat prevention, but I wouldn't mind some more layered defense, as long as it doesn't impact customers. We pretty much bypass all M365 traffic via a couple of unwieldy rules, and I am planning to clean them up. Before I do this, however, if anyone is inspecting M365 traffic, I'd like to hear your experiences.

Dave

[the_rock]

Hey Dave,

I know customer that used to do that, not any longer. Im almost positive the reason they stopped was because it eas causing them too many headaches along the way, since they always had to end up bypassing things.

[Nüüül]

Out of M365 Network Principles M$ says avoid any deeper inspection (which TLS Inspection definitively is).

Click to Expand

Bypass proxies and inspection devices

Configure browsers with PAC files that send Microsoft 365 requests directly to egress points. Configure edge routers and firewalls to permit Microsoft 365 traffic without inspection.

Minimize latency Reduce load on network devices

I´d stick to MSXFAQ ( M365 und SSL Inspektion, saying avoid inspecting endpoints ( M365 Endpoints Worldwide - API ) that are flagged with "Optimize" and "Allow" as category. "optimize" endpoints you could try with TLS Inspection.

AFAIK - with this you will not get hands on files that are moved around in OneDrive and co. But enabling TLS Inspection will pretty sure cause problems with the application. 

Sharepoint and Teams chances are good, you won´t get a good hand on on network level.

Other vendors have things like "tenant control" to stick users to their own tenant or control where they might access.. not sure if Check Point offers something in that direction. 

[the_rock]

Excellent advice @Nüüül 

[David_C1]

This is the path I am headed - excluding those ranges marked with Optimize and Allow. Ideally, Check Point would break down the updatable objects for Office365 Services based on these tags - otherwise I'm stuck with some manual work, verifying when these "optimize" and "allow" ranges are updated and changing my rules based on that. I will likely end up using a broader stroke - just bypassing essentially everything in the Office365 Services updatable objects group.

[the_rock]

I agree 100%, seems totally logical to me as well.

[Nüüül]

here are several scripts and so on that you could use to build your own updatable objects. perhaps you would need to adopt them a bit for using those flags.

but yes, thats some extra work.

[Lesley]

Dave,

Do you run R82? There are many new features that make your life for easy. (learning mode: https://support.checkpoint.com/results/sk/sk182679 )

And certificate pinning:

Starting from R82, several new features were added to further address the challenges posed by certificate-pinned applications:

• Full Fail-Open Mode: Automatically detects failures in the HTTPS Inspection process due to client-side issues like pinned certificates. When a failure is detected, the connection is added to an exception list, ensuring zero connectivity issues for end-users.
• Allow Lists: In addition to the well-known HTTPS services, this list includes known certificate-pinned applications identified through learning and analyzing similar connection behaviors, allowing users to decide whether to bypass them.

Second tip: you can bypass the 'recommended' websites listed in https://support.checkpoint.com/results/sk/sk163595

Start building new policy maybe with a few test clients, or your own machine.

So rule 1 is your client and bypass and rule 2 inspect.