[EN] OneCheck Deep Dive: Pre-boot Auth, Password S...

jorgeluiznim

Article 12 of the Harmony Endpoint Deep Dives series · A note on management: Harmony Endpoint is cloud-managed (Infinity Portal / Web Management) in most deployments today. OneCheck is configured under Policy > Data Protection > OneCheck. Where an on-premises Management Server behaves differently, that is called out.

Purpose

FDE encrypts the disk, but who gets in, and how many times they can get it wrong, is decided by OneCheck. This article covers OneCheck User Settings end to end: the Pre-boot authentication methods (password, Smart Card, dynamic token), password synchronization, account lockout, Single Sign-On, and the Remote Help that rescues locked-out users on the road.

Audience

[x] Endpoint Administrators
[x] Security Engineers
[x] Help Desk / IAM teams
[ ] SOC Analysts
[x] Beginners

Prerequisites

Full Disk Encryption Deep Dive (Article 10), OneCheck configures the Pre-boot that FDE creates
FDE policy configured (most OneCheck settings relate to Pre-boot)

Where OneCheck Fits

OneCheck defines how users authenticate to Endpoint Security clients: the authentication method, whether they must also log on to Windows, what happens on invalid credentials, access-count limits, and whether Remote Help is allowed. Because much of this is Pre-boot behavior, the Full Disk Encryption policy must also be configured. Settings live under Policy > Data Protection > OneCheck, with subsections for Password Constraints, User Account Lockout Settings, Remote Help and OneCheck Logon Settings, and apply after the policy is installed.

diag1-preboot-flow

Three Ways to Authenticate at Pre-Boot

Method	Notes
Password	Username + password, the default Pre-boot method. Can match the Windows password or be created separately. New Pre-boot user passwords need ≥ 5 characters
Smart Card	A physical card tied to a certificate. E80.30+ clients only. Needs the card, an active certificate, and Smart Card drivers. Not supplied by Check Point, use third-party/vendor software
Dynamic Token	A device that generates a new password each boot. Assigned per user (not the global method). Add/import via Manage > Dynamic Token Management (DES key = 14 chars, 3DES = 42 chars)

The global setting is either Authenticate users with Password or Authenticate users using Smart Card or Password; per-user you can override to Password, Smart Card, Either, or Dynamic Token.

Smart Card rollout without lockouts

The killer setting: "Change authentication method only after user successfully authenticates with a Smart Card." Users keep using passwords until their Smart Card works once, then they must use the card. Without it, a Smart-Card-only user who isn't fully set up cannot log in with a password at all.

Best Practice: always use that option for Smart Card migrations, put all Smart Card users in a Virtual Group to monitor them, and watch the Pre-boot Reporting reports during rollout.

Smart Card certificates can be scanned from AD, either all certificates or only those with the Smart Card Logon OID 1.3.6.1.4.1.311.20.2.2. In the FDE rule, Enable USB devices in pre-boot environment must be on for the reader to work.

Smart Pre-boot: Self-Unlock and Mobile Login (E89.05+)

Beyond the classic methods above, recent clients add Smart Pre-boot, which became Generally Available in E89.05 (it was Early Availability before). It modernizes the Pre-boot step with two capabilities:

Self-Unlock, which lets a user recover access at Pre-boot on their own, without a help desk call.
Mobile Login, where the user approves the Pre-boot logon through multi-factor authentication (MFA) on a smartphone.

Smart Pre-boot rides on the Full Disk Encryption Pre-boot, so it is planned together with FDE. The encryption side and the rollout details live in the Full Disk Encryption Deep Dive (Article 10) and the E89.x release notes. For environments standardizing on E89.x, Smart Pre-boot is the direction Check Point is taking the Pre-boot experience, cutting lockouts and help desk load.

Password Synchronization: One Password, Two Worlds

Pre-boot and Windows are separate credential stores. Sync keeps them equal:

Action	Direction
Update Pre-boot password upon Windows change	Windows → Pre-boot
Update Windows password upon Pre-boot change	Pre-boot → Windows
Bi-directional update	Either change updates the other
Do not synchronize	Independent

The change propagates via the regular heartbeat and sync messages to every computer the user is authorized on. If a computer was offline when the password changed, the update arrives after it reconnects, so the user may need to log in one time with the old password first.

diag2-password-sync

Warning: Password Synchronization only works if Pre-boot authentication is enabled, and the Windows + Pre-boot password rules must match, mismatched complexity is the classic cause of first-logon failures.

Account Lockout: Failed-Attempt Defense

Setting	Default threshold
Temporarily lock the account	5 failed attempts
Permanently lock the account (until admin unlocks)	10 failed attempts

Extra controls: temporary-lockout duration (minutes), and a max successful logons limit, handy for temporary users (e.g., allow N logins then lock). Note: Remote Help is not available for the "max successful logons" lockout type.

Logon Settings & Single Sign-On

Advanced logon options:

Allow logon to a system hibernated by another user, a different user authenticates at Pre-boot to a hibernated machine
Allow use of recovery media, authenticate to use recovery media (in E80.20+, recovery media made with a temporary user still works even if this is off)
Allow user to change credentials from the client, change the password during Pre-boot
Allow Single Sign-On use, SSO for Pre-boot and Windows when OneCheck Logon is disabled

Note: SSO here applies only to Pre-boot and Windows, not VPN or Media Encryption. When OneCheck Logon is running, users always get SSO. The clean setup for AD shops: User Acquisition + OneCheck Logon + Password Synchronization so one credential unlocks Pre-boot and Windows.

Remote Help: Rescuing the Locked-Out User

Two flavors, for the user stranded without access:

Type	Use
One Time Login	Access for one session without resetting the password, required if a user loses a Smart Card, dynamic token, or hits too many failed attempts
Remote password change	For fixed-password users who forgot their password

Note: for devices protected by Media Encryption & Port Protection, only Remote password change is available (no One Time Login).

Enable Allow remote help, then grant receive remote password change and/or receive One-Time Logon per account.

Assigning Pre-Boot Users (the order that matters)

Users are added to an entity (device/group/OU) in this resolution order:

Direct Users → 2. Inherited Users → 3. Direct Groups → 4. Inherited Groups

Adding an AD group directly assigns its users (no user acquisition needed), and new members are auto-assigned later. Hard limit: 1000 users per group per entity, exceeding it is blocked (excess users flagged in red).

You view, create, lock and unlock Pre-boot users from the Authorize Pre-Boot Users window (search by device to see the authorized users per device, then Create New Pre-boot User: password ≥ 5 chars, or a Dynamic Token; optional expiration, default Never).

Best Practices

Best Practice: for AD environments, combine User Acquisition + OneCheck Logon + Password Synchronization so users have one credential for Pre-boot and Windows.

Best Practice: align Windows and Pre-boot password requirements before enabling sync, mismatch breaks first logon, OneCheck Logon and SSO.

Best Practice: for Smart Card rollouts, use change method only after successful Smart Card auth and group all Smart Card users for monitoring.

Best Practice: for a Smart-Card-only user who needs recovery media, create a temporary user who can authenticate to it when the media is made.

Common Mistakes

Mistake	Impact	Solution
Smart-Card-only without the "after successful auth" option	Users can't log in until fully provisioned	Use the gradual-rollout option
Mismatched Windows vs Pre-boot password rules with sync on	First Pre-boot logon / SSO fails	Match the complexity policies
Enabling sync without Pre-boot auth	Sync doesn't work	Pre-boot authentication must be enabled
Expecting Remote Help on a "max successful logons" lockout	No Remote Help for that type	Use standard lockout, or unlock manually
Assuming SSO covers VPN/Media Encryption	It doesn't (only Pre-boot + Windows)	Plan those separately
Group over 1000 users on one entity	Excess users unassigned	Split groups / respect the 1000 cap

Troubleshooting

Symptom: After a password change, a user can't authenticate at Pre-boot on one laptop Environment: OneCheck with Password Synchronization, multiple devices Root Cause: That laptop was offline when the password changed, so it still has the old Pre-boot credential Resolution:

Have the user log in once with the old password at Pre-boot
Ensure the client connects to the server (heartbeat/sync delivers the new credential)
Confirm Windows and Pre-boot password rules match (prevents recurrence)
If truly locked out, use Remote Help (One Time Login or Remote password change per policy)

FAQ

Q: What's the default Pre-boot method? A: Password (username + password). Smart Card (E80.30+) and Dynamic Token are alternatives.

Q: How many failed attempts trigger lockout? A: 5 for temporary, 10 for permanent (defaults). A "max successful logons" option also exists for temporary users.

Q: Does SSO cover VPN too? A: No, SSO here is Pre-boot + Windows only. VPN and Media Encryption are separate.

Q: A user lost their Smart Card, how do they get in? A: One Time Login via Remote Help grants a single session without resetting the password.

Q: Minimum password length for a new Pre-boot user? A: 5 characters.

References

Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal), Configuring the Data Protection Policy > OneCheck (Password Constraints, User Account Lockout Settings, Smart Card, Remote Help, OneCheck Logon Settings, Authorize Pre-boot Users)

Revision History

Date	Version	Author	Changes
2026-07-16	1.0	Jorge Luiz	Initial version
2026-07-30	2.0	Jorge Luiz	Cloud-first revalidation: configuration under Policy > Data Protection > OneCheck (Password Constraints / User Account Lockout Settings / Remote Help / OneCheck Logon Settings); Authorize Pre-Boot Users window; added the password-sync diagram; References point to the cloud Administration Guide
2026-10-07	2.1	Jorge Luiz	Added Smart Pre-boot (GA in E89.05: Self-Unlock and Mobile Login via MFA); style pass for clean prose

Supported Versions: Harmony Endpoint cloud management (Infinity Portal / Web Management); Windows clients (Smart Card E80.30+; Smart Pre-boot Self-Unlock and Mobile Login E89.05+) Last Updated: 2026-10-07