Harmony Endpoint On-Premises Architecture: Components, Communication Flows & Ports

[jorgeluiznim]

Article 1 of the Harmony Endpoint Deep Dives series · Endpoint Security Management R81.20 (on-premises) · Author: Jorge Luiz

Purpose: map the complete architecture of a Check Point Endpoint Security on-premises environment (R81.20): every component, every communication channel, every port — so you can design, firewall, and troubleshoot your deployment with confidence.

Audience: Security Engineers, Endpoint Administrators, SOC Analysts — beginner friendly.

Prerequisites: basic familiarity with Check Point management concepts (SmartConsole). No prior Harmony Endpoint knowledge required.

Overview

Check Point Endpoint Security is an integrated suite that combines data security, network security, advanced threat prevention, forensics, and remote access VPN — all managed centrally from a single console.

An on-premises environment is built from three mandatory elements plus two optional ones:

Component	Role
Endpoint Security Management Server	Holds policy management and databases (policies, user/computer objects, licensing, monitoring data). Communicates with clients to update components, policies and protection data. Contains the Directory Scanner, which reads the Active Directory structure for directory-based policy assignment.
SmartEndpoint	The SmartConsole application used to deploy, monitor and configure Endpoint Security clients and policies.
Endpoint Security Clients	Software on end-user computers that monitors security status and enforces policies.
Endpoint Policy Server (optional)	Improves performance in large environments by handling most client communication: heartbeat and sync requests, policy downloads, Anti-Malware updates, and client logs.
Secondary Management Server (optional)	High Availability — a backup server if the primary goes down.

ℹ️Note: in Check Point documentation, "Endpoint Security Management Server" refers to all Endpoint Security servers in the environment — including the optional Endpoint Policy Servers.

ℹ️Note: the Active Directory Server is the repository of your organization's user information, but it is not part of the Endpoint Security Management Server.

How It Works — Communication Flows

1. Client → Server: the client is ALWAYS the initiator

This is the single most important architectural fact for firewall design: endpoint clients always initiate the connections. The server never connects "down" to a client.

Service (Protocol/Port)	Communication	Notes
HTTPS (TCP/443)	Most communication (TLSv1.2)	e.g., endpoint registration, new file encryption key retrieval
HTTPS (TCP/443)	Policy downloads	The policy files themselves are encrypted with AES
HTTPS (TCP/443)	Heartbeat	Periodic; reports policy status and compliance changes
HTTPS (TCP/443)	Application Control queries	Reputation of unknown applications
HTTPS (TCP/443)	Log uploads	Client logs sent to the server
Proprietary Check Point protocol	Sensitive services	FDE Recovery Data Upload, Media Encryption & Port Protection Key Exchange, FDE User Acquisition & credentials
HTTPS (TCP/80)	Anti-Malware signature updates	The engine verifies signatures before loading and during the update
HTTPS (TCP/443)	Client package downloads	Packages are signed and verified on the client before installation

⚠️Warning: make sure that HTTP (TCP/80) and HTTPS (TCP/443) services and ports are allowed by Firewall or Application Control rules, and that there is routing between all Endpoint Security elements. Missing either is the classic root cause of "agent not communicating".

2. Console & Server → Server (SIC)

Communication between management elements uses Check Point Secure Internal Communication (SIC) — the elements authenticate each other with certificates.

Service (Protocol/Port)	Communication
SIC (TCP/18190–18193)	SmartEndpoint console → Management Servers
SIC (TCP/18190–18193)	Endpoint Policy Server → Management Servers
SIC (TCP/18221)	Secondary → Primary Management
HTTPS (TCP/443)	Endpoint Policy Server → Primary Management (monitoring events)

3. The Heartbeat — small message, big responsibilities

Every 60 seconds (default), each client initiates a heartbeat to its server. The heartbeat:

1. Confirms connectivity
2. Reports policy status changes
3. Updates the endpoint's Compliance state

The heartbeat also drives the compliance enforcement state machine — by default, a client is restricted after 5 consecutive out-of-compliance heartbeats:

Configuration

Tuning the heartbeat interval

1. In SmartEndpoint, click Manage > Endpoint Connection Settings
2. In Connection Settings, set the Interval between client heartbeats
3. In Out-Of-Compliance, set "Client will restrict non compliant endpoint after" (default: 5 heartbeats)
4. Click OK

💡Tip: shorter interval = fresher compliance data but more management load. Longer interval = less load but staler logs and reports. 60 seconds is the balanced default.

Enforcing TLSv1.2 only

By default the servers accept TLSv1.2 and TLSv1. To restrict to TLSv1.2 only, on each server:

cpstop
# Back up first:
cp -v $UEPMDIR/apache/conf/ssl.conf{,_BKP}
# Edit $UEPMDIR/apache/conf/ssl.conf and change:
#   SSLProtocol +TLSv1 +TLSv1.2   -->   SSLProtocol TLSv1.2
cpstart

SHA-256 management certificate

On R80+ clean installations the management certificate is SHA-256 by default. For environments upgraded from R77.x or lower, SHA-256 can be used for renewed certificates after the previous one expires:

cpca_client set_sign_hash sha256

Per sk103840, the underlying mechanics are important to understand:

• In R77.x and lower, the Internal CA (ICA) issues certificates based on SHA-1 by default; in R80.xx, SHA-256 signs the ICA by default.
• Certificates issued by the ICA inherit the signature algorithm of the ICA certificate. Old certificates issued by an old SHA-1 ICA root stay SHA-1 even after the ICA root is recreated with SHA-256 — they must be renewed/recreated to pick up SHA-256.

To check the signature algorithm of the ICA certificate (Expert mode on the Management Server):

cpopenssl pkcs12 -in $FWDIR/conf/InternalCA.p12 -nokeys -nomacver -passin pass: | cpopenssl x509 -noout -text | grep "Signature Algorithm"
# SHA-256 output: Signature Algorithm: sha256WithRSAEncryption

ℹ️Note: if the ICA is still SHA-1, see sk158096 (ICA certificate renewal). Two facts from that SK worth knowing: the ICA certificate is valid for 20 years and historically did not renew automatically — automatic renewal (one year before expiration) was introduced starting with R82 and recent Jumbo Hotfix Takes (R81.20 JHF Take 26+). And if the ICA expires, new certificates it signs (SIC, IKE, user) are created already expired — renew at least 2 weeks before expiration.

Best Practices

✅Best Practice: use Endpoint Policy Servers in large or multi-site environments. Why: they offload heartbeat/sync, policy downloads, Anti-Malware updates and client logs from the Management Server, and reduce inter-site bandwidth.

✅Best Practice: deploy a Secondary Management Server. Why: guarantees a backup management if the primary is down.

✅Best Practice: when replacing SSL certificates, push the new CA certificate to a small OU first, migrate servers/clients gradually, and do the primary and secondary servers last. Why: clients without the matching CA cannot send SSL messages (e.g., FDE payloads, audit logs) to a server whose certificate they don't trust.

Common Mistakes

Mistake	Impact	Solution
TCP/80 or TCP/443 blocked between client and server	Agents appear offline, no policy/signature updates	Allow both ports in Firewall/App Control rules; verify routing
Replacing a server SSL certificate before pushing the matching CA to clients	Clients can't send FDE payloads and audit logs to that server	Follow the gradual replacement flow (CA first, small OU, servers last)
Expecting the server to reach out to clients	Misdesigned firewall rules	Remember: the client is always the initiator
Forgetting Install Database on the secondary server after installing an SSL certificate (HA)	Inconsistent HA behavior	Always repeat Install Database on the secondary

Troubleshooting

Symptom: clients show as disconnected / policies never arrive
Environment: R81.20 on-premises management, any client version
Root Cause (most common): TCP/80 and/or TCP/443 not allowed between client and server, or missing routing between elements

Resolution:

1. Confirm the client can reach the server on TCP/443 (and TCP/80 for Anti-Malware updates)
2. Check intermediate Firewall / Application Control rules
3. Verify routing between all Endpoint Security elements
4. Check certificate trust if SSL certificates were recently replaced

FAQ

Q: Which ports do I need to open for endpoint clients?
A: TCP/443 (HTTPS — nearly all traffic) and TCP/80 (Anti-Malware signature updates). The client always initiates.

Q: What exactly does an Endpoint Policy Server take over?
A: Heartbeat and synchronization requests, policy downloads, Anti-Malware updates, and client log collection.

Q: Is the heartbeat configurable?
A: Yes — default 60 seconds, in Manage > Endpoint Connection Settings. The out-of-compliance restriction threshold (default 5 heartbeats) is configured in the same place.

Q: Are policy files protected in transit?
A: They travel over HTTPS (TLSv1.2) and the policy files themselves are AES-encrypted. Sensitive payloads (FDE recovery data, ME&PP key exchange, FDE credentials) additionally use a proprietary Check Point protocol.

References

• Check Point R81.20 Endpoint Security Administration Guide (PDF) — chapters "Introduction to Endpoint Security" and "Endpoint Security Architecture"
• Introduction to Endpoint Security (online version)
• sk103840 — SHA-1 and SHA-256 certificates in Check Point Internal CA (ICA) (content verified 2026-07-16)
• sk158096 — How to renew an Internal Certificate Authority (ICA) certificate (content verified 2026-07-16)

---

Supported Versions: Endpoint Security Management R81.20 (on-premises)  |  Last Updated: 2026-07-16  |  Author: Jorge Luiz  |  Article 1 of the Harmony Endpoint Deep Dives series