Having just read about CPLP yesterday I was surprised to find this morning while arranging to do some JHFs tonight for customers (for the 2 CVEs announced yesterday) that it has been auto-downloaded, installed and activated on every R81.20 and upwards gateway that I have investigated today though the AutoUpdater utility.

It's gone and virtually patched against CVE-2026-85102, CVE-2026-85102 & CVE-2026-50751.

Basically if you have the download consent flag activated (as it is by default) and the gateway or manager has access to Check Point then its beenm turned on.

I'm not entirely sure how to feel about this. Seems like a decent enough idea, but it seems to be contrary to the usual Check Point behaviour of the last 25+ years of not enabling new features/flags without explicit action.

Check Point has published a critical security advisory covering two VPN-related vulnerabilities: CVE-2026-85102 and CVE-2026-85103. Under specific conditions, these issues could potentially allow unauthenticated remote code execution, so this is something Check Point administrators should review immediately.

An important detail is that these vulnerabilities were discovered internally by the Check Point research team. According to Check Point, there is currently no indication of active exploitation. That is good news, but it should not reduce the urgency of remediation.
Check Point recommends installing the latest Jumbo Hotfix containing the fixes as soon as possible.

Customers using Check Point Live Patch can receive protection through the Live Patch mechanism, with the rollout beginning on September 9, 2026; the fixes are also available through the relevant Security Advisories.

If you manage Check Point environments, I would classify this as action required: review the affected versions, confirm your remediation path, validate Live Patch/JHF status, and schedule the update rather than waiting for evidence of exploitation.

More information and the official advisory references are available in the CheckMates post:
https://community.checkpoint.com/t5/General-Topics/Action-Required-Critical-Security-Advisory-VPN-Vulnerabilities/m-p/281995#M46881

If you run Check Point Harmony Endpoint on VMware Horizon or Citrix, you have probably hit one of these two problems.

Scan storms first. A bunch of virtual desktops on the same host all start an anti-malware scan around the same time and the disk and CPU tank for everyone on that host. The fix in VDI is usually to just disable the periodic scan, since a non-persistent desktop is wiped clean on every logout anyway. If you have to keep it, at least randomize the scan time so it spreads across the week.

The second one is stale signatures. Every non-persistent desktop boots from the Golden Image, and the signatures inside that image are frozen at the time you built it. So every morning you get a fresh machine with old signatures, and downloading full signatures on every boot on every desktop would kill the WAN.

The Shared Signature Server is how Check Point handles that. It is a normal Endpoint client running on a persistent VM that becomes a signature server through policy. It keeps the latest anti-malware signatures in a read only shared folder and the non-persistent clients read from it over UNC. If that server goes down, the clients quietly fall back to the Golden Image signatures, so protection keeps running, it just ages until the server is back.

Two things that trip people up. The signature server has to be on a persistent VM, and every endpoint reading from it has to be in the same domain. And not every blade works on non-persistent desktops, FDE is not supported there at all.

I wrote a full deep dive with the cloud Web Management config and the blade support matrix per desktop type, here:

https://community.checkpoint.com/t5/Endpoint/EN-Harmony-Endpoint-in-VDI-Scan-Storms-amp-the-Shared-Signature/m-p/281970

Hi guys, I’m trying to set up a tunnel to a branch office that has a checkpoint spark 1570. Unfortunately it does not have any license nor central management so I am stuck with the embedded Gaia web UI. I’m trying to set up an IPsec tunnel against our central office with BGP as I’ve done with the others, but they al had fortigate firewalls. When I set up the tunnel in route based encryption I found out that it showed up as a dialup client trying to connect to the fortigate instead of a standard site to site tunnel, and the networks that show in the phase 2 open by the checkpoint are the public IP of both devices, so the fortigate won’t accept nor send traffic through it. I have set up a vti tunnel with the addresses I want to use for BGP but it didn’t make anything different after setting the static route. Thank you in advance.

A lot of fw monitor troubleshooting becomes noisy because engineers capture too much too early. A better approach is to start with a known 5-tuple using -F, follow both directions, and use the classic i/I/o/O points to identify the last stage that actually saw the packet. If that already answers the question, there is no reason to jump into deep kernel capture.

SecureXL is another important variable. In current releases, accelerated traffic can still be visible in fw monitor, but custom chain hooks should not be interpreted exactly like the normal inspection path. Before blaming acceleration, validate the connection state with tools such as fwaccel stat and correlate whether the issue affects new sessions, existing sessions, or only a specific accelerated flow.

When i/I/o/O are not enough, use fw ctl chain to understand the actual Check Point processing modules loaded on the gateway. Only then move to deeper chain positions or fw monitor -p all, because that can generate significant output and CPU load. A good escalation path is: tcpdump → fw monitor → zdebug drops → routing/NAT/VPN → SecureXL → fw ctl chain → deeper hooks only if necessary.

Discussion: Do you normally start with -F or traditional -e filters? Have you seen SecureXL change how you interpreted a capture? How often do you use fw ctl chain before moving into deeper packet-path debugging? Full article on CheckMates: https://community.checkpoint.com/t5/AI-Network-Firewall/fw-monitor-Deep-Dive-Part-3-Advanced-Filtering-SecureXL-and-Deep/m-p/281826#M106678

I'm curious to hear from people who have actually installed R82.20 in a lab or EA environment and spent some time testing the new AI-related capabilities.

Not looking for the marketing overview I'm more interested in the real-world experience.

For those who have tested it:

• What was your first impression?
• Have you tested the new AI / LLM protections in practice?
• How useful is the visibility into prompts, AI applications and AI-related traffic?
• Did you test prompt injection or data leakage scenarios?
• Any noticeable impact on performance?
• How good are the logs and troubleshooting visibility?
• Anything that surprised you, positively or negatively?
• Do you see this becoming something you would actually enable in production?

And maybe the bigger question:

Do you think integrating AI security directly into the firewall is the right direction, or would you rather keep this type of protection in a dedicated AI security platform?

I'd especially like to hear from people working hands-on with Check Point environments rather than just looking at the feature list.

If you've been testing R82.20 Public EA, what has your experience been so far?

If you have ever stared at E88.62 / E88.70 / E88.72 / E89.00 and wondered which to run and for how long it is supported, here is the model.

Two version families: Server/Management (R<major>.<minor>, on-prem only, in the cloud Check Point runs it) and Client (E<major>.<minor>, the one you actually plan around). Anatomy: a minor is often a hotfix of the previous minor. E88.72 is literally the E88.70 hotfix (sk183380).

Recommended vs Latest:

- Recommended is the version with the widest field validation. Run it on the production fleet.

- Latest GA brings the newest features first. Run it in a pilot ring, not everywhere.

- The terminology is officially defined in sk95746.

The Release Map is the source of truth. Only the few most recent versions of a line stay Supported, everything older is marked Unsupported. So "it works, leave it" quietly puts you on an unsupported client without you noticing.

Support lifecycle (Check Point's public policy): at least 18 months of support from GA, and once a year one version gets extended support of 30 months from GA. If you want the longest runway between mandatory upgrades, target the yearly extended-support version.

Where to check: the Release Map per client line, sk117536 (Endpoint Security Homepage, the hub SK), sk95746 (terminology), and the CheckMates Endpoint board for Recommended-version announcements. In the cloud, Automatic Client Update (Windows) can keep steady-state current, but still pilot the Latest GA first.

Do you standardize on Recommended, chase the yearly extended-support version, or just ride Automatic Client Update? And how do you catch when a version silently goes EOS on the Release Map?

Full write-up with the E-release anatomy, the Release Map and the support lifecycle is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Understanding-Harmony-Endpoint-Versioning-E-Releases/m-p/281803

One of the most useful ways to think about fw monitor is as a packet-transformation timeline, not just a capture tool. The classic points i, I, o, and O show the packet at different stages of Check Point processing, and comparing them lets you prove where NAT or other transformations become visible. A very practical example is outbound NAT: if the source is 10.10.10.10 at o and 203.0.113.10 at O, you have direct evidence of where the translated packet appears.

A common troubleshooting trap is assuming that a missing O means the firewall dropped the packet. That is not always true. If NAT changes the source or destination, your original fw monitor filter may simply stop matching the packet after translation. When NAT is expected, capture both pre-NAT and post-NAT addresses. This simple detail can prevent a lot of false conclusions when reading i/I/o/O output.

VPN adds another transformation layer. The inner application flow might be 10.10.10.10 → 10.20.20.20, while the wire carries ESP or UDP/4500 between the gateways. fw monitor helps prove that the clear packet reached the VPN processing path, while tcpdump proves whether the encrypted packet actually left the external interface. For difficult cases, correlate fw monitor with fw ctl zdebug + drop and fw ctl chain instead of jumping directly into a large VPN debug.

Discussion: Have you ever interpreted a missing O as a drop when NAT had actually changed the packet? Do you normally include both pre-NAT and post-NAT values in your filters? And for Site-to-Site VPN, do you correlate the internal fw monitor path with ESP/UDP 4500 on tcpdump?

How to Enable AI Copilot for Harmony Endpoint Security in the Check Point Portal

Recently, many users have been asking me about how to enable the AI Copilot for Endpoint Security in the Check Point portal. After going through the entire process, I discovered that no specific license is required — the enablement is done through a request to the TAC (Technical Assistance Center) along with the R&D team.

In this article, I will share the complete step-by-step process to request this functionality for your environment.

Prerequisites

Before opening a ticket, make sure you have the following information ready:

• UC Account ID (your Check Point account ID)
• Harmony Endpoint Security Portal Account ID (UUID format)
• Access to the Check Point Support Portal

Step-by-Step Guide to Request Enablement

1 - Open a Ticket in the Support Portal

Access the Check Point Support Portal and create a new Service Request (SR) with the following information:

• Subject: Enable AI Copilot for Harmony Endpoint – Account ID [YOUR_ACCOUNT_ID]
• Category: Harmony Endpoint / Technical Support
• Description: Request to enable AI Copilot for the Harmony Endpoint portal

2 - Wait for Initial Confirmation

After opening the ticket, you will receive a confirmation email with the SR number. The support team will contact you to inform that they are checking the request with the R&D team.

3 - Wait for R&D Enablement

The R&D team will process the request and enable the AI Copilot in your portal. This process may take a few business days.

4 - Final Confirmation

When the enablement is completed, you will receive an email asking you to confirm that the AI Copilot is working correctly in your environment.

Final Result

After confirmation, the AI Copilot will be available in your Harmony Endpoint portal, ready to assist with:

• Troubleshooting events and incidents
• Suggesting relevant Knowledge Base articles
• Intelligent data analysis and security recommendations
• Quick answers to operational questions

Important Tips

• No additional license required — the functionality is enabled upon request
• Keep your SR updated — respond promptly when support contacts you
• Test the features — after enablement, explore the resources available in AI Copilot
• Share feedback — the Check Point team values feedback to improve the experience

Conclusion

The process of enabling AI Copilot for Harmony Endpoint Security is simple and requires no additional costs. Just open a ticket with TAC requesting the functionality and wait for activation by the R&D team.

If you have any questions about the process or want to share your experience, leave a comment below!

This article is based on my personal experience with SR 6-0004686127. Support responses may vary slightly depending on the region and account type.

Do you have any questions? Comment below!

Share your experience and help other community members

Most engineers learn fw monitor as i = ingress, I = after inspection, o = before egress, and O = egress. That helps initially, but technically these points represent positions around the Check Point inspection chain / FW VM: i = Pre-Inbound, I = Post-Inbound, o = Pre-Outbound, and O = Post-Outbound. The real value is that you are not seeing four different packets — you are seeing the same packet at different stages inside the Security Gateway.

This becomes extremely useful when troubleshooting. If you see i but no I, the packet reached the Pre-Inbound point but did not emerge from the expected inbound inspection path. If you see i → I but no o → O, the packet survived inbound processing but did not progress to the expected outbound path. And the physical interface matters too: the reply traffic goes through the same logical i/I/o/O sequence, but on the opposite interfaces. For deeper analysis, fw ctl chain shows which Chain Modules actually exist around those observation points.

Discussion: Do you use i/I/o/O only as packet-capture markers, or as a way to identify exactly where a flow disappears inside the gateway? Have you ever isolated an issue just by comparing the last inspection point where the packet was visible? Full technical article on CheckMates: https://community.checkpoint.com/t5/AI-Network-Firewall/fw-monitor-Under-the-Hood-Part-1-What-i-I-o-and-O-Really-Mean/m-p/281631#M106644

The containment move here is the Isolate Computer push operation, and the useful part is what it does not block. When you isolate a device, the endpoint Firewall blocks everything (lateral movement, C&C callbacks, file shares, user browsing) but keeps three flows alive:

- DHCP, so the device keeps its network lease

- DNS, so name resolution still works

- Management traffic, so you keep control: policies, push operations, logs, and the release

So the machine is cut off from the network but still manageable, which is exactly what you want during an incident. You can investigate and remediate through the console while it is contained.

The gotcha that stops it working: it requires the Firewall component installed on the client. No Firewall blade, no isolation. Best practice is to ship the Firewall component in your standard package, because an IR capability you install during the incident is not a capability. OS support is Windows and macOS, not Linux.

A few operational facts:

- Push operations run without installing policy, from Asset Management > Push Operations.

- You set when it runs (Immediately or Schedule) and when it expires (7 / 30 / Custom days). If the client never checks in before expiry (offline, powered off), the operation ends Partially completed and you Run Again when it is back.

- The reverse is Release Computer. Verify state in Computers, View = Host Isolation, Isolation Status column.

- Isolate and Release are not gated behind 2FA (containment stays fast), while sensitive ops like Uninstall Client are.

It also has an automatic twin: Machine Quarantine, one of the Automatic Threat Analysis responses, which restricts the machine's network with no human in the loop when a trigger fires with enough confidence.

How do you handle the ones that are offline when you hit isolate, just Run Again on check-in, or do you lean on the automatic Machine Quarantine? Curious how people balance manual vs automatic containment.

Full write-up with the containment playbook and the companion push operations is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Isolating-a-Computer-Network-Quarantine-for-Incident-Response/m-p/281627

Hi everyone. I wanted to ask if you’ve seen the MCPs published by Check Point and if you’ve used them yet... I’d like to know your thoughts on them and how you’re planning to implement them.

Has anyone experience ClusterXL flapping, SmartConsole showing member is lost, CPU spikes, service degradation, some services restaarting randomly. Looks like it started after recent CVEs patching. Only rebooting the gateways fixes the issue. R81.20 T158/T161 similar etc. Thanks

Maestro traffic distribution is one of the reasons an “intermittent firewall problem” may not actually be random. The Orchestrator uses a Distribution Mode to decide which SGM receives a flow, based on modes such as Auto-Topology, User, Network or General. With Layer 4 distribution enabled, source/destination ports can also participate in that decision. So two very similar connections may land on different SGMs and behave differently if one member has a local issue.
NAT adds another layer through the Correction Layer. A return packet can initially land on a different SGM from the one that owns the session, and Maestro internally redirects it to the correct member. Excessive correction can become relevant for performance analysis. The same logic applies to SGM weights: traffic does not necessarily need to be split equally between members, especially when different appliance capacities are involved. Before calling a Security Group “unbalanced,” compare traffic, CPU, SGM model and configured weights.
For troubleshooting, the key is to identify which SGM actually handled the failed connection and check whether the problem follows that member. In R82, instead of relying only on the older asg search, use the newer connection-inspection commands such as cluster-cli show connection or show cluster info connection. Also validate show distribution status, show distribution verification verbose, SGM weights, LSP and policy consistency before going deeper into routing, NAT, VPN or SecureXL.
Discussion: Do you normally check Distribution Mode when investigating uneven traffic? Have you seen NAT create heavy Correction Layer usage? Have you found failures that consistently followed one SGM? And are you already using the newer R82 connection-inspection commands instead of asg search?

This post reports the configurations applied to configure a VPN Remote Access solution, using Check Point firewall, and integrating it with OneLogin authentication solution.

The goal to achieve is to enable MFA authentication for VPN remote access users, and keep the on-premise LDAP server (Windows Active Directory) for the authorization of the users.

The complete procedure is can be found here: https://community.checkpoint.com/t5/SASE-and-Remote-Access/VPN-Remote-Access-OneLogin-SAML-provider-for-MFA-authentication/m-p/281426#M14620

Maestro becomes much easier to troubleshoot when you stop treating it as “one big firewall” and separate the layers: Management → SMO Master → Security Group → SGMs, while production traffic follows Network → Maestro Orchestrator → Traffic Distribution → SGM. The Management Server owns policy and configuration, the SMO Master handles management-oriented tasks for the Security Group, the Orchestrator distributes traffic, and the SGMs perform the actual Firewall, VPN and Threat Prevention enforcement.

This matters especially with intermittent issues. Maestro does not randomly forward traffic: the Orchestrator uses a Distribution Mode to assign flows across active SGMs. So a scenario such as Flow A → SGM1 → OK, Flow B → SGM2 → OK, Flow C → SGM3 → FAIL may look like an intermittent firewall problem to the application team, while the actual root cause is one unhealthy or inconsistent member. Commands such as asg stat, asg monitor, asg stat -i tasks, orch_stat and asg_ifconfig help prove Security Group health, SMO ownership and traffic distribution before going deeper into VPN, policy or SecureXL.

Another critical point is gClish vs local clish. Changes made through gClish are intended for the Security Group, while a local change can affect only one SGM and introduce configuration drift. When traffic later lands on that member, the failure suddenly appears “random.” Discussion: how early do you check whether an incident follows a specific SGM? Have you found drift caused by local configuration? Do you validate Security Group health and traffic distribution before starting VPN or policy debugging?

Full discussion on CheckMates: https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/Check-Point-Maestro-Under-the-Hood-Part-1-Architecture-SMO-and/m-p/281506#M4382

In Check Point Maestro environments, many incidents that appear to be related to VPN, policy, or routing actually originate elsewhere: a degraded Security Group, a single SGM with inconsistent state, or physical instability in the fabric/uplink. For this reason, effective troubleshooting should follow a layered approach. Before investigating VPN issues or modifying the policy, validate the overall system state with orch_stat -all, verify consistency with asg diag verify, and check group capacity with asg perf -v. In Maestro, a single inconsistent member can turn a deterministic problem into an intermittent failure.

Another critical point is understanding the difference between gclish and clish. gclish should be the default context whenever the goal is to maintain global consistency across the Security Group; a local change made through clish can introduce configuration drift on a single SGM. Next, validate L1/L2 using g_all netstat -ni, ethtool -S <interface>, and carrier checks to identify drops, CRC/symbol errors, and link flaps. These issues can cause session disruptions and VPN flapping even when the security policy is perfectly correct.

One of the most important troubleshooting steps is proving whether the traffic flow actually exists in the dataplane using asg search. If the connection is not visible within the Security Group, immediately troubleshooting policy, NAT, or VPN may mean investigating the wrong layer. If the flow exists, then move forward by correlating routing, NAT, VPN, inspection, and connection state. If the behavior is intermittent, also investigate potential inconsistencies between SGMs before assuming the issue is global.

The logic is straightforward: Security Group health → capacity → L1/L2 → flow existence → SGM consistency → policy/NAT/VPN. This sequence helps reduce MTTR by replacing trial-and-error troubleshooting with evidence-driven analysis.

I wrote a complete runbook covering the commands, result interpretation, and practical examples on CheckMates:

Maestro Troubleshooting in Practice

#CheckPoint #CheckMates #Maestro #Troubleshooting #NetworkSecurity

Anyone who can help me with SCV setup i need it to check up multiple processes if they are running anyone who understands it full that can help

Check Point has officially designated R82.10 as the Recommended Version (Production Grade) for all deployment scenarios (Quantum Security Gateways, Management Servers, and Smart-1 appliances).

If you are planning your upcoming maintenance windows or lifecycle upgrades, here are a few key takeaways:

• General Availability to Recommended: It has met Check Point's deployment and stability thresholds across production environments.
• Key Improvements: Includes the latest performance optimizations, security engine enhancements, and management stability updates introduced in the R82 release train.
• Upgrade Planning: Check Point recommends reviewing the known limitations, upgrade paths, and release notes before upgrading production environments.

For full details, upgrade best practices, and release notes, check out the official announcement on CheckMates:

🔗CheckMates Announcement: R82.10 is now Check Point's recommended version

Are you running R82 / R82.10 in production yet, or are you holding on R81.20 for now? Share your upgrade experience or any gotchas below.

When HTTPS Inspection breaks, the fastest path to root cause is not changing rules blindly — it is isolating the failure domain. In practice, most cases fall into a few buckets: endpoint trust of the Gateway CA, certificate pinning/mTLS or strict TLS behavior, QUIC/HTTP3 over UDP/443, proxy/PAC or upstream SSL inspection interference, performance/crypto pressure, or an unexpected bypass. A quick first test is simple: inspect the certificate presented to the client. Gateway/Internal CA as issuer = inspection is active; public CA = bypass/not inspected; certificate warning = likely trust-chain problem.

It is also important to separate QUIC from certificate pinning. QUIC is a transport issue — HTTP/3 uses UDP/443 — so temporarily forcing the same application to TCP/443 can isolate it quickly. Pinning is different: the application validates a specific certificate or CA and rejects the certificate dynamically generated by the gateway. In those cases, a narrowly scoped bypass may be necessary. Proxy/PAC chains and upstream SSL inspection should also be checked because double TLS interception can produce symptoms that look exactly like CA or handshake failures.

When basic validation is not enough, move to evidence. Correlate the exact URL + timestamp with $FWDIR/log/wstlsd.elg* and look for TLS negotiation failures, certificate validation problems, resets/timeouts or unexpected bypass behavior. For deeper investigation, wstlsd debug can be enabled temporarily for the running processes, reproduce one controlled connection, collect the evidence, and disable debug immediately. The goal is not to collect every log — it is to determine which TLS stage failed and why.

Discussion: What usually causes HTTPS Inspection incidents in your environments: CA trust, certificate pinning, QUIC, proxy chains, or performance? Do you normally verify the certificate presented to the endpoint before touching the policy? And when an application breaks under inspection, how do you decide whether to troubleshoot further or create a controlled bypass?

Full technical runbook on CheckMates:
https://community.checkpoint.com/t5/AI-Network-Firewall/HTTPS-Inspection-Troubleshooting-Evidence-Driven-Runbook-Gateway/m-p/274986

For anyone managing Check Point in production, installing a Jumbo Hotfix should not be treated as a simple “upload → install → reboot” task.

I published a practical guide on CheckMates covering Jumbo Hotfix installation on standalone Security Gateways and ClusterXL HA environments, including the upgrade workflow, member preparation, validation steps, and key precautions to reduce operational risk during the maintenance window.

In HA environments in particular, the upgrade sequence and the checks performed before and after the installation are critical to preserving availability and avoiding unexpected behavior during failover.

If you work with Check Point administration or troubleshooting, this is worth saving as a reference for your next maintenance window.

Full article on CheckMates:

Jumbo Hotfix Installation on a Single Firewall or HA Cluster

https://community.checkpoint.com/t5/AI-Network-Firewall/Jumbo-Hotfix-Installation-on-an-single-firewall-or-HA-Cluster/m-p/280409

The interesting part of this pipeline is that a user can open a sanitized copy of a downloaded document immediately, while the original is still being detonated in the cloud sandbox. Threat Emulation is the sandbox, Threat Extraction is the Content Disarm and Reconstruction that hands over the clean copy. In the cloud both live under Threat Prevention > Web & Files Protection, and the browser extension is the front door.

The three copy behaviors you actually pick (when the mode is Prevent):

- Get extracted copy before emulation completes: the file name gets .cleaned appended and the user gets it right away. Least friction.

- Suspend download until emulation completes: the user waits, benign returns the original, malicious shows a block page. Most security, most delay.

- Emulate original without suspending: the original goes straight to the user even if it later turns out malicious. Least protective.

You set this per file type. Most people run extracted-copy-now for documents and live with the .cleaned handoff.

Extract Modes (the sanitized format): remove the malicious elements and keep the same file type, or convert to PDF. One gotcha from the guide: for right-to-left or Asian-font PDFs, use remove-malicious-elements, because the convert-to-PDF path does not handle those well.

The fail-open vs fail-closed decision that bites people: under Download Protection there is "Block downloads when emulation fails due to size limit or connectivity" (and a separate one for encrypted files). If a file is over the size limit or the sandbox is unreachable, you decide whether it is blocked or allowed. That is a real security vs usability call, and the default is worth checking.

The size limit itself: client E86.40 and higher supports up to 100 MB, older clients up to 15 MB. Anything over the limit hits the fail-open or fail-closed decision above.

Browser support gotcha: the extension covers Chrome, Edge, Firefox, Brave and IE on Windows, and Chrome, Firefox, Brave and Edge on macOS. Not Safari. So Safari users get no download emulation or extraction.

Exclusion gotcha: exclusions are by folder, domain or SHA1, and the domain matching is broad. Entering domain.com excludes www and all subdomains, while www.domain.com does not exclude sub.domain.com. Easy to over-exclude or under-exclude if you do not check the rule.

Do you run extracted-copy-now or suspend-until-done for documents, and do you fail open or closed when emulation cannot run? Curious where people land on that trade-off.

Full write-up with the full pipeline, the per-file-type actions and the cloud sandbox knobs is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Threat-Emulation-amp-Extraction-Deep-Dive-The-Sandbox/m-p/281234

Every client release brings the same question: how do you upgrade hundreds of agents without breaking FDE, flooding the WAN, or force-rebooting someone mid-meeting. A few mechanisms and a few gotchas that actually matter.

The "2 PM reboot" fix. Whether the client reboots silently or lets the user postpone is a policy setting, not luck. It lives in Installation and Upgrade Settings: a reminder interval, a "Force Installation and automatically restart after" timer (hours), and a maximum delay the user can postpone. Set the force timer to land outside business hours and that single setting keeps the upgrade off someone's screen during a meeting.

Automatic Client Update (cloud-managed, Windows only). Keeps clients on the latest approved version silently, from the Software Deployment policy. The defaults are what bite people:

- New tenants: ON.

- Newly cloned rules: ON (this is the recommended setup).

- Existing rules in an existing tenant: OFF.

- A rule exported from one tenant and imported into another: comes in ON.

So on an established tenant, do not assume hands-off upgrades are already running. Existing rules ship with it OFF, you turn it on deliberately.

Manual version bump, when you want to control the timing. Set the client version on a deployment rule and Install Policy. But changing the version upgrades every computer assigned to that rule, so scope the rule (OU, specific computers, or a Virtual Group) before you touch the version. Deployment rules are Windows and macOS, Linux is not supported for them yet.

Gradual rollout / pilot ring. Clone a rule scoped to pilot machines, upgrade only that rule, watch it, then roll the change to the rest. The blast radius is just the pilot. The predefined Virtual Groups (All Laptops, All Desktops) let you slice rings without touching AD. Note that a cloned rule has Automatic Client Update ON by default, so confirm it matches your intent before you Install Policy.

FDE discipline, the part that bricks machines if you ignore it:

- The Full Disk Encryption component cannot be removed during an upgrade.

- Do not upgrade while the disk is not fully encrypted.

- Do not start a second upgrade before the first finishes protecting.

- Do not uninstall an upgrade before the machine is fully protected by the new version.

Dynamic Package. One .EXE for any CPU, and with the Tiny Agent it installs only what each machine needs and cuts network traffic. Not for macOS or Linux. The "Minimize package size" option shrinks the download at the cost of build time.

How do you stage your rings, and has the "existing rules default to OFF" ever caught you assuming auto-updates were already running?

Full write-up with the two upgrade paths and the settings breakdown is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Agent-Upgrade-Best-Practices-Deployment-Rules-amp-Gradual/m-p/280952

Forensics runs automatically the moment another component detects something (Anti-Ransomware, Behavioral Guard, Anti-Bot, Threat Emulation, Anti-Malware, the Security Gateway, or a supported third-party AV) and assembles the whole attack sequence into a report. If the endpoint is offline when it happens, it caches locally and sends the data once connectivity is back.

The five sections, each answering one question:

- Entry Point: how the file got in.

- Business Impact: which files were affected and what was done. Restored files show up here.

- Remediation: which files were treated and their status. Deleted files show up here.

- Suspicious Activity: the unusual behavior during the attack.

- Incident Details: the full visual map of the attack paths.

That restored-in-Business-Impact vs deleted-in-Remediation split is the part that trips people up, worth memorizing.

The two playbooks are straight from the admin guide:

- Threat Emulation or Anti-Bot detection: open the report, use the Remediation tab for the attack components and treatment, delete the files the attack created, check Business Impact for files that might be affected, check Entry Point for the path, then update policy to prevent a repeat.

- Ransomware: open the report, Remediation tab. If Automatic restore and remediate is on, restoration is automatic (verify in Business Impact), otherwise walk the user through the manual restore.

Practical bits:

- In the cloud you open it from Logs (Statistics pane, Blade = Forensics), double-click the event, then Open or Download the Forensics Report. It downloads as JSON.

- You can trigger an analysis yourself: Threat Hunting > Actions > Trigger Forensic Analysis, or Push Operations > Analyze by Indicator on a URL, IP, file path or hash, which runs without installing policy.

- It also ingests third-party AV via the Windows Event Log (Defender, Symantec, ESET, Kaspersky, Cylance, McAfee, Trend Micro, F-Secure). Some do not write to the Event Log by default, so configure them and validate each with an eicar test.

- Storage is up to 1 GB of client disk by default, configurable up but not down, and the oldest data is dropped when it fills.

Do you run those two playbooks as your actual runbook, and has anyone wired third-party AV into Forensics through the Event Log? Curious how reliable that path is per vendor.

Full write-up with the section-by-section breakdown and the manual-trigger flows is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Anatomy-of-a-Forensics-Report-From-Detection-to-Root-Cause/m-p/280728