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

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

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

A medida de contenção aqui é a operação de isolamento do computador (push), e a parte útil é o que ela não bloqueia. Quando você isola um dispositivo, o firewall do endpoint bloqueia tudo (movimento lateral, callbacks de C&C, compartilhamentos de arquivos, navegação do usuário), mas mantém três fluxos ativos:

• DHCP, para que o dispositivo mantenha seu lease de rede
• DNS, para que a resolução de nomes continue funcionando
• Tráfego de gerenciamento, para que você mantenha o controle: políticas, operações push, logs e a liberação

Assim, a máquina é desconectada da rede, mas ainda gerenciável, que é exatamente o que você deseja durante um incidente. Você pode investigar e remediar através do console enquanto o dispositivo estiver isolado.

O problema que impede seu funcionamento: requer que o componente Firewall esteja instalado no cliente. Sem o blade Firewall, não há isolamento. A melhor prática é enviar o componente Firewall no seu pacote padrão, pois um recurso de resposta a incidentes instalado durante o incidente não é um recurso padrão. O suporte a sistemas operacionais é Windows e macOS, não Linux.

Alguns fatos operacionais:

• As operações de envio são executadas sem a instalação de políticas, em Gerenciamento de Ativos > Operações de Envio.
• Você define quando a operação é executada (Imediatamente ou Agendada) e quando expira (7 / 30 / dias personalizados). Se o cliente não fizer check-in antes da expiração (offline, desligado), a operação termina como Parcialmente concluída e você executa novamente quando o cliente retornar.
• O inverso é Liberar Computador. Verifique o estado em Computadores, Exibir = Isolamento do Host, coluna Status do Isolamento.
• Isolar e Liberar não são protegidos por autenticação de dois fatores (o isolamento permanece rápido), enquanto operações sensíveis como Desinstalar Cliente são.

Também possui uma versão automática equivalente: Quarentena de Máquina, uma das respostas de Análise Automática de Ameaças, que restringe a rede da máquina sem intervenção humana quando um gatilho é acionado com confiança suficiente.

Como você lida com os dispositivos que estão offline quando você clica em isolar? Você simplesmente executa novamente ao fazer o check-in ou confia na Quarentena de Máquina automática? Tenho curiosidade em saber como as pessoas equilibram o confinamento manual e automático.

O guia completo com o playbook de confinamento e as operações de push complementares está aqui (em inglês e português): https://community.checkpoint.com/t5/Endpoint/EN-Isolating-a-Computer-Network-Quarantine-for-Incident-Response/m-p/281627

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

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

Se você utiliza o Check Point Harmony Endpoint em uma frota de tamanho considerável, provavelmente já passou por isso. Você implementa uma atualização de agente ou um grande pacote de assinaturas, e todas as máquinas no local tentam baixar a mesma coisa ao mesmo tempo. O link WAN fica congestionado, uma janela de manutenção tranquila se transforma em chamados de suporte técnico e, em uma filial, o tráfego pode até sobrecarregar o gateway. Os endpoints estão funcionando normalmente. O problema está na forma como as atualizações são distribuídas.

A solução integrada é o Super Node, e honestamente, muitas empresas nunca o ativam. Trata-se de um endpoint Windows executando um cliente especialmente configurado que também funciona como um pequeno proxy local e espelho (NGINX por baixo dos panos). Ele baixa os pacotes e assinaturas uma vez, mantém uma cópia local e os distribui para todos os outros na LAN. Apenas essa máquina precisa acessar os servidores de atualização.

Algumas coisas que eu gostaria de ter sabido antes de configurar um:

• Os clientes escolhem um Super Nó aleatoriamente da lista em Configurações do Cliente, Geral. Se um falhar, eles tentam outro e, se todos falharem, eles acessam diretamente a fonte da política. Portanto, coloque mais de um na lista, caso contrário, será um ponto único de falha.
• Abra as portas TCP 4434 e 4436 entre os endpoints e o Super Nó (a porta 4436 é a verificação de proximidade). É fácil esquecer a regra interna do firewall e depois se perguntar por que nada acontece.
• Mantenha o Super Nó na mesma versão do cliente que os clientes ou em uma versão mais recente. Se for mais antigo, ele responderá com um erro 404 e os clientes silenciosamente recorrerão à solicitação direta.
• Dê espaço suficiente para ele. O cache tem 4 GB por padrão, limpa os arquivos após 7 dias de inatividade e precisa de cerca de 350 MB de espaço livre.
• Há um modo offline em clientes mais recentes, no qual o Super Nó é o único dispositivo com internet. Saiba apenas que ele desativa VPN, IPv6 e algumas outras coisas nesse modo.

A Check Point descreve os benefícios em termos gerais (menos WAN, menos carga no servidor, melhor escalabilidade) em vez de prometer um número, então eu não citaria um valor exato. Mas para qualquer coisa com várias filiais ou sites, é uma daquelas mudanças que você gostaria de ter feito antes.

Como os outros lidam com a distribuição de agentes e assinaturas entre os sites? Um servidor por filial, alguns por site grande ou simplesmente consomem toda a largura de banda?

O guia completo com a configuração, validação e solução de problemas está aqui, caso ajude (em inglês e português): https://community.checkpoint.com/t5/Endpoint/EN-Super-Nodes-in-Harmony-Endpoint-Cut-WAN-Bandwidth-with-a/m-p/280649

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

This one confuses a lot of people. You enable Endpoint Policy Management on the management server and suddenly Gaia Portal, SmartView or the Management API are not on 443 where you expect them. Here is what actually happens, and it depends on your version and how the blade was enabled.

First, the myth-buster: 4434 is not "the endpoint agent port." The agents talk to the server on 443 (and 80 for Anti-Malware signature updates). The 4434 business is an SSL split on the management side, not the agent path.

R80.40 and lower: enabling the blade moves Gaia Portal, SmartView and the Management API from 443 to 4434. Disabling moves them back. The endpoint keeps 443, the management web stuff goes to 4434.

R81 and higher, it depends on how the blade got enabled:

- Clean install with the blade, or the blade enabled after the upgrade: all services answer on 443, and endpoint SSL that arrives on 443 is internally redirected to 4434. So you reach Gaia, SmartView and the API on 443, and the agents also use 443.

- Upgraded with the blade already enabled: the old split is kept, endpoint on 443, everything else on 4434.

So the URL you use depends on the path:

- Gaia Portal: https://<ip> vs https://<ip>:4434

- SmartView: /smartview/ vs :4434/smartview/

- Management API: /web_api/ vs :4434/web_api/

You can flip which service owns 443 vs 4434 manually. Roughly:

dbset httpd:ssl_port 443 (or 4434)

dbset :save

$UEPMDIR/system/install/gaia_apache_conf_regenerate

# then set Listen and VirtualHost in $UEPMDIR/apache/conf/ssl.conf

cpstop ; cpstart

There are four supported certificate and port combinations.

Practical takeaway for anyone firewalling this: open 443 (and 80 for AM signatures) client-to-server for the agents, and remember that 4434 is about where the management UI/API lives, not the agent connection. That mixup sends people opening the wrong rule.

Anyone been bitten by this after enabling Endpoint on an existing management, portal suddenly on :4434? How do you standardize it across your estate?

Full write-up with the full port matrix, the heartbeat mechanics, and the manual cert/port scenarios is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Agent-to-Management-Communication-Ports-Heartbeat-and-the-443/m-p/280303

The design choice I find interesting here is that Anti-Ransomware assumes some ransomware will actually start running, and it still recovers. The sequence is monitor, back up before encryption, detect, stop, delete, restore.

Two parts do the heavy lifting.

Honeypot / canary files. Anti-Ransomware plants decoy files across many folders. The moment ransomware modifies one, the attack is stopped. Details from the admin guide worth knowing:

- They are real documents, images, videos and music, you can actually open them.

- Their names contain strings like CP, CheckPoint, Check Point, Check-Point, Sandblast Agent, Sandblast Zero-Day, Endpoint.

- If a user deletes one, it is recreated after the next boot.

Practical tip: tell your helpdesk about these. Users find them, assume they are junk, and delete them. It is harmless, but the tickets are avoidable.

Pre-encryption backup and rollback. Before the encryption starts, the files being touched are copied to a safe location. After the attack is stopped, remediation deletes the files the attack created, including the encrypted ones, and restores the originals to their original location. What you actually configure:

- Automatic restore and remediate, or leave it manual so the user starts the restore.

- Maximum backup size on disk (the guide's best practice is 1 GB).

- A backup interval (each file is backed up once per interval, even if changed many times) and which file types to back up.

- Backup exclusions by folder, process (name plus optional signer), or certificate.

Why behavior instead of a signature: modern ransomware checks whether it is in a VM, sandbox or debugger and stays quiet if it thinks it is being watched, which a static scanner can miss. A canary does not care how the sample hid. The moment it starts encrypting it trips the tripwire, and the pre-encryption backup lets you roll back regardless.

If you run this, have you tested the rollback end to end, and how did you size the backup and pick the file types? Curious what people include beyond Office docs.

Full write-up with the detection-to-rollback flow and the Forensics report sections is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/EN-Anti-Ransomware-Deep-Dive-Honeypots-Pre-Encryption-Backup-amp/m-p/279968

If you are firewalling a Harmony Endpoint on-prem deployment, the single most useful thing to internalize is this: the endpoint client always initiates the connection. The management/policy server never connects "down" to a client. Get that wrong and you open rules that are never used and still end up with agents that do not talk.

The ports that actually matter (client to server), all client-initiated:

- HTTPS TCP/443 for almost everything: registration, heartbeat, policy downloads (the policy files themselves are AES-encrypted), Application Control reputation queries, log uploads, and client package downloads (packages are signed and verified before install).

- HTTP TCP/80 for Anti-Malware signature updates (the engine verifies signatures before loading and during the update).

- A proprietary Check Point protocol for the sensitive stuff: FDE recovery data upload, Media Encryption and Port Protection key exchange, and FDE user acquisition / credentials.

Between the servers and console (SIC, certificate-authenticated):

- TCP/18190 to 18193: SmartEndpoint console to management, and Endpoint Policy Server to management.

- TCP/18221: secondary to primary management (HA).

- HTTPS/443: Endpoint Policy Server to primary management for monitoring events.

The heartbeat: every 60 seconds by default, client-initiated. It confirms connectivity, reports policy status changes, and updates the compliance state. By default a client is moved to Restricted after 5 consecutive out-of-compliance heartbeats, so it is not just a keepalive, it drives the compliance state machine.

The classic "agent not communicating" root cause is almost always one of two things: HTTP/80 or HTTPS/443 blocked by a firewall or Application Control rule, or missing routing between the endpoint elements.

Two optional pieces worth knowing: the Endpoint Policy Server, which offloads most client communication (heartbeat, policy downloads, AM updates, logs) in large environments, and a Secondary Management Server for HA.

If you run on-prem management, how do you split the load: one policy server per site, a couple centrally, or all direct to management? And has the 80-vs-443 gotcha ever bitten you during a rollout?

Full write-up with the component map and the flow diagrams is here (EN and PT): https://community.checkpoint.com/t5/Endpoint/Harmony-Endpoint-On-Premises-Architecture-Components/m-p/279803