Check Point Quantum Gateway Hardening Guide: Admin Access, Remote Access VPN and Gaia Baseline

A Check Point Quantum Security Gateway and its Security Management Server hold the keys to your perimeter, so the administrator accounts, remote access users, API keys and integration credentials around them need the same care as the rule base itself. Apply Check Point's recommended Jumbo Hotfix Accumulator and security updates promptly, and follow the Check Point support centre for advisories. This guide covers how administrator and user identity work across SmartConsole, the Security Management Server and Gaia OS, the hardening values Check Point publishes, the logs that matter, and how to recover an appliance you no longer trust. It is for firewall engineers, network architects and SOC analysts who run Quantum gateways. For the cross-vendor view, see the VPN Security Guide.

This is an independent guide from NHI Mgmt Group, based on Check Point's public documentation as of November 2026. It is not sponsored or reviewed by Check Point. Product features change, so confirm settings against Check Point's current documentation.

Key takeaways

• Manage the management plane first. Put the Security Management Server on a dedicated management segment, restrict SmartConsole to Trusted Clients and jump hosts, and reach it over VPN rather than directly from the internet.
• Put administrators behind an identity provider with MFA. SAML login for SmartConsole administrators, named accounts only, a quarterly account review and one controlled break-glass account.
• Remove password-only remote access users. Check Point's remote access guidance gives a script to find local users who authenticate with a password alone and a hotfix setting to block them.
• Treat integration credentials as privileged non-human identities. Read-only directory and cloud accounts, API keys with a two-month validity, and no keys in clear-text repositories.
• Change the Gaia defaults. Check Point's own hardening table raises the minimum password length from 6 to 10, turns on lockout and two-factor authentication, restricts Expert mode and moves SNMP to v3 only.

How identity and access work in Check Point Quantum

A Quantum deployment has three identity planes that are configured in different places. Hardening one does not harden the others.

Two machine identities sit between these planes. Secure Internal Communication (SIC) certificates let the management server and gateways trust each other, and integration accounts (LDAP, cloud controllers, identity providers, API keys) let Check Point read from other systems. Both appear in Check Point's post-incident rotation lists, which is a good indicator of how much trust they carry.

Admin roles and privileged access

SmartConsole administrators

• Identity provider login: Check Point documents SAML login for SmartConsole administrators with Okta, Ping Identity and Microsoft Entra ID. Create an Identity Provider object, assign it under Manage & Settings > Permissions & Administrators > Advanced > Identity Provider, then create administrators or administrator groups with a permission profile. The administrator name must match the IdP username attribute, and the group ID must match the IdP group attribute. See the SAML Security Guide.
• One IdP per server or domain: a Security Management Server supports one identity provider, and on a Multi-Domain Server each domain supports one, assigned by a super user.
• Break-glass account: Check Point recommends keeping at least one administrator who does not authenticate through the IdP, for when the IdP is unavailable. Store its credentials offline and alert on every use. See the Break-Glass Account Guide.
• Session behaviour to know: editing or disconnecting an IdP administrator object does not end an active session, so terminate sessions explicitly when you remove someone. Where an administrator has both an account and group membership, the account's permissions apply.
• Permission profiles: give day-to-day operators read-only or limited profiles, and reserve Super User for a small named group. The Management API Login permission and the Run Repository Script and Manage Repository Scripts gateway permissions are worth reviewing on their own, because they allow automation and command execution across gateways.

Settings Check Point recommends

Gaia OS users

Gaia accounts are separate from SmartConsole administrators. Review every Gaia user on each gateway and management server, set each user's shell to /etc/cli.sh (Gaia Clish) under User Management > Users, and create a role under User Management > Roles that sets Clish Environment, Expert Mode, Expert Authentication Method, Expert Password and Expert Password Hash to None or Read Only. Assign that role to most administrators so Expert mode, which is a full Linux shell, stays with a small group. Check Point also describes a Playblocks automation, "Notify for Expert Shell login", which it says does not need a Playblocks subscription. For session recording on jump hosts, see the Privileged Session Management Guide.

Integrations, API tokens and service accounts

Check Point's hardening guide asks for integration credentials with the least privilege they need, read-only where possible, and kept apart from interactive administrator accounts.

Limit where the management API listens. In SmartConsole under Manage & Settings > Blades > Management API > Advanced Settings, the access options are Management server only, All IP addresses that can be used for GUI clients (the Trusted Clients list) and All IP addresses. Choose the narrowest one your automation allows, publish, and run api restart. Check Point also documents a setting, disabled by default, that discards open API and SmartConsole work sessions older than a threshold (60 days by default); enabling it removes stale sessions. For API key handling across products, see the API Key Management Guide and the Service Account Security Guide.

Logging and detection

• Get Gaia logs off the box: on gateways, enable "Send Syslog messages to management server" under Gaia Portal > System Management > System Logging (disabled by default). On the management server, add a remote syslog server and keep a short local copy for troubleshooting.
• Log the implied rules: implied rules run by default, but their logging is disabled by default. Check Point recommends turning it on for visibility.
• Log the stealth rule: log drops of traffic aimed at the gateway itself during rollout, then tune. Scans against the gateway become visible here.
• Review remote access logins: Check Point's remote access guidance gives a log query for password-based Mobile Access logins: blade:"Mobile Access" AND action:"Log In" AND auth_method:Password. Run it across the last three months and investigate unfamiliar users, sources and times.
• Watch the management plane: SmartConsole audit logs for new administrators, permission profile changes, Trusted Client changes, API settings changes, policy installs outside change windows and repository script runs.

For detection content shared across firewall and VPN vendors, see the VPN and Firewall Log Detection Guide.

Metrics that show it is working: percentage of administrators authenticating through the IdP with MFA (target 100 percent except break-glass); number of password-only remote access users (target zero); gateways on the recommended Jumbo Hotfix (target 100 percent within your patch window); integration credentials past their two-month validity (target zero); gateways sending syslog with a heartbeat in the last hour; days since the last quarterly administrator review.

Hardening baseline

Gaia password policy

Check Point's Gaia hardening guidance lists these defaults and recommended values under Gaia Portal > User Management > Password Policy.

Palindrome checks, reuse checks and SHA512 hashing are already on by default. If a server has been upgraded many times, reset passwords so they are re-hashed with the stronger function.

Services, management plane and policy

• Services: run only OpenSSH (TCP 22), Gaia Portal HTTPS (TCP 443), cprid (TCP 18208) and the Gaia REST API (TCP 443), reachable only from trusted internal networks.
• Management server placement: behind a firewall on a dedicated management VLAN, reachable from admin jump hosts, the gateways it manages (for SIC, policy and logs) and log servers. Avoid direct internet administration and require VPN. Web SmartConsole needs only TCP 443; installed SmartConsole uses TCP 18190, 18264 and 19009 (sk52421 has the full port list). See the Network Device Management Plane Hardening Guide.
• Stealth rule: near the top of the rule base, allow admin jump hosts and admin groups to the gateway for HTTPS, SSH or API as needed, then drop and log everything else aimed at the gateway.
• Implied rules: keep them enabled unless you fully replace them, and enable their logging. Replacing them with explicit rules (sk179346) is for high-security environments only, because a mistake can break policy installation and management connectivity.
• Remote access users: find local users who authenticate with a password only, then block them with the blockSFAInternalUsers setting added by the hotfix described in sk182336, moving users to certificates or an external MFA-backed method. Check that CCCD is disabled with vpn cccd status.
• SNMP: v3-Only, agent on internal interfaces only, USM users with AES256 privacy and SHA512 authentication, read-only. Disable SNMP if unused. See the SNMP Security Guide.
• Dynamic routing: enable only the protocols you use, allow only routing peers to reach the gateway, use BGP MD5 authentication rotated every 90 days and inbound route filters.
• Lights Out Management: never on the internet; dedicated management network, allow-listed sources, monitored access.
• Updates: run a supported release with the recommended Jumbo Hotfix (sk95746), and in SmartConsole Global properties > Data Access Control select the option to automatically download and install security updates, then install the Access Control policy.

Rollout order and rollback

1. Export a Gaia snapshot and a management database backup, and confirm out-of-band access works.
2. Restrict Trusted Clients, management API access and management server reachability. Test from every jump host before removing old sources.
3. Configure the IdP for SmartConsole with one pilot group; keep the break-glass account and confirm it works before moving everyone.
4. Apply the Gaia password policy and Expert mode role on one gateway, check that automation and backups still log in, then roll out.
5. Add the stealth rule and implied rule logging with logging on; watch for dropped management or cluster traffic for a few days.
6. Move remote access users off password-only authentication in groups, communicating with each group first, then enable blocking.
7. Rollback: revert the policy to the last installed revision in SmartConsole, or restore the Gaia snapshot; keep the change log so each step can be undone separately.

Common misconfigurations

• Shared admin and Gaia accounts: the same "admin" credentials on every gateway, with Expert mode for everyone. Use named accounts, the Clish shell and a restricted role.
• Management server reachable from too many places: Trusted Clients left open, or API access set to all IP addresses for convenience.
• Password-only internal VPN users: left over from testing or emergencies, with no review of their login logs.
• Over-privileged directory account: the LDAP Account Unit or AD Query running as a Domain Admin rather than a dedicated read-only account. See the RADIUS Security Guide for the related shared secret risks.
• Long-lived API keys in scripts: automation keys never expire and live in plain text in a repository.
• Incomplete rotation after an incident: rotating administrator passwords but not HTTPS Inspection certificates, VPN and portal certificates, Log Exporter TLS certificates, SNMP pass phrases or backup credentials. sk182336 lists each of these.

If you no longer trust an appliance

Check Point's recovery chapter sets this order: decide what evidence to preserve before anything is overwritten; isolate the LOM card; reinstall Gaia from verified media with the ISOmorphic tool (sk65205); restore only configuration backups that predate the suspected compromise; install current updates; reinstall LOM firmware and change its credentials where the model supports it; validate before returning to service; and rotate administrator credentials, certificates, keys and tokens. If a known-good state cannot be reached, contact Check Point support and consider hardware replacement. For the investigation itself, see the Edge Device Compromise Investigation Playbook.

Framework mapping

Practitioner checklist

• Move SmartConsole administrators to SAML with MFA, keep one offline break-glass account, and review accounts quarterly.
• Set administrator expiry, 10-character minimum passwords, a 10-minute idle timeout and lockout under Permissions & Administrators > Advanced.
• Restrict Trusted Clients and management API access, and place the management server on a dedicated segment reached over VPN.
• Apply the Gaia password policy values, enable two-factor authentication on R82 and later, set Clish as the shell and restrict Expert mode by role.
• Find and block password-only remote access users; confirm CCCD is disabled.
• Scope LDAP, cloud controller and API credentials to read-only where possible, and set API keys to a two-month validity.
• Add a stealth rule, enable implied rule logging and send Gaia syslog to the management server and a SIEM.
• Keep every gateway on the recommended Jumbo Hotfix and enable automatic security updates.
• Keep a tested rotation list of every certificate, shared secret and service credential for use after an incident.

Standards and references

• Check Point: Gateway and Management Hardening, Administrator Identity and Access Control
• Check Point: Gateway and Management Hardening, Gaia OS Hardening
• Check Point: Gateway and Management Hardening, Management Plane Protection
• Check Point: Gateway and Management Hardening, Limiting Third-Party Integration Credentials
• Check Point: Gateway and Management Hardening, Appliance Recovery Following a Security Incident
• Check Point: sk182336 Remote Access VPN and Mobile Access security recommendations
• Check Point: Creating an Administrator Account with SAML Authentication Login
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: VPN Security Guide · Network Device Management Plane Hardening Guide · Firewall Rule Review Checklist · Phishing-Resistant MFA Guide