Skip to content

Guides

Check Point releases, Jumbo Hotfix Accumulators and Take numbers explained

What a major release, a Jumbo Hotfix Accumulator and a Take are, how Check Point designates recommended releases and Takes, what a Take's notes tell you about a vulnerability, and why Patcharo keeps three facts apart.

Who it is for
Engineers who run Check Point Quantum security gateways and management servers and read Takes in SK articles, advisories and inventories.
Scope
Gaia-based gateways and management (Quantum Security Gateway, Quantum Security Management). Not Quantum Spark builds, Harmony or CloudGuard, which have their own numbering.

Published 30 Sept 2026 · Updated 23 Oct 2026 · Sources checked 19 Oct 2026

Major release, Jumbo Hotfix Accumulator, Take

Check Point names its major releases with an R and a number: R81.10, R81.20, R82, R82.10. A major release is installed once; afterwards it is maintained by a Jumbo Hotfix Accumulator (often written JHF or Jumbo), one per release, which bundles the fixes published since the release. The accumulator is delivered in successive packages called Takes, each identified by a number that only grows. A device therefore runs a release and a Take, and both are needed to describe it: a release with its Take says more than the release alone.

Check Point's FAQ describes the accumulator as cumulative: a Take contains the fixes of the earlier Takes of the same release, so moving from an early Take to a later one brings everything published between them. The accumulator never crosses releases: a Take of R81.20 says nothing about R82, which has its own accumulator and its own numbering.

WrittenWhat it isWhere Check Point documents it
R81.20A major releasesk95746 (release terminology), the Support Life Cycle Policy (dates)
R81.20 Take 173The Take 173 of the Jumbo Hotfix Accumulator for R81.20, installed on an R81.20 deviceThe Jumbo Hotfix Accumulator documentation of R81.20: release date, adoption level, resolved issues
Take 173 – Initial AdoptionThe adoption level Check Point states for the latest Take on the Downloads pageThe same documentation, Downloads page
sk95746The article that names the recommended version for all deploymentsCheck Point Support Center
Identifiers written as Check Point writes them; the Take numbers are an example of the form, not a statement about the current Take. A dated example written for this guide; the current releases are in the live block and on the product pages.

The recommended version for all deployments

The article sk95746, Check Point Recommended Version and Release Terminology, names one version that Check Point recommends for all deployments, with its latest Jumbo Hotfix Accumulator Take. It also lists the release dates of the current releases and the terminology of the release types. This statement answers the question “which release should a new or migrating deployment run?”. It does not say that an older release is unsupported, nor that a given Take fixes a given vulnerability.

Patcharo shows the recommended version apart from everything else, as it last read sk95746, with the day of that reading. Check Point's website is not read automatically since 23 October 2026 (its terms subject automated reading to Check Point's written permission): the version shown is the one verified until then. The live block at the end of this guide carries it.

How Check Point designates recommended Takes

For years, Check Point declared specific Takes of each accumulator as Recommended on a given date: the documentation of a release read “released on …, declared as Recommended on …” under the designated Take, and the other Takes were available without that designation. Operators waited for the Recommended Take before a wide roll-out.

The policy stated in sk95746 since September 2026 is different: every new Take of a Jumbo Hotfix Accumulator becomes the recommended one on the day it is released. The adoption level shown on the Downloads page of a release's documentation (Initial Adoption, then Wide Adoption) describes how far Check Point has seen the Take deployed; it is a maturity signal, not a different recommendation. Under this policy the recommended Take of a release is its latest released Take, and it moves with every release of a new Take.

A Take once declared Recommended under the former policy stays recommended only in history. When a Take is withdrawn or replaced, the vendor's documentation says so on the Take's own entry: read it rather than a download page cached elsewhere.

What a Take's notes say about a vulnerability

The documentation of each release's accumulator lists, for every Take, the issues it resolves. When a fix closes a vulnerability, the entry names the CVE identifier and usually the SK article of the vulnerability. The first Take whose resolved issues name a CVE is the first fixed Take of that release for that CVE; the vulnerability's own SK article often names it too, sometimes with a hotfix for releases that have no Take with the fix yet.

  • A Take whose notes do not name the CVE is not a fix for it, even if it is newer than a Take that does elsewhere: read the entry.
  • The first fixed Take is historical: once a Take fixes a CVE, every later Take of the same release contains the fix too (the accumulator is cumulative), but the first fixed Take stays that one.
  • Two documents naming different Takes for the same CVE (the SK and the notes) are a contradiction to resolve by reading both, never by picking the larger number.
  • A device whose Take is unknown cannot be declared fixed: Check Point's fix is a Take, and an inventory that records only the release records half the version.

Why latest, recommended and supported are kept apart

Three statements describe an R81.20 gateway and answer three different questions. The latest Take of its accumulator says what exists; the recommended version of sk95746 says what Check Point advises for all deployments, which may be another release altogether; the Support Life Cycle Policy says until when R81.20 receives fixes. A gateway on the latest Take of a release that is not the recommended version is up to date and still not on the recommended release; a gateway on the recommended release with an old Take is on the recommended release and still missing fixes.

Patcharo shows the three statements on separate lines with their sources and never merges them: the first fixed Take per CVE from the accumulator's notes and the SK, the current Take of each release from the accumulator's documentation under the vendor's policy, the recommended version from sk95746, and the support dates from the life cycle policy.

The current Check Point statements, as the catalog reads them

Below are the vendor's statements as Patcharo last read them, with the day of verification: the recommended version, and for each supported release the latest Take announced by its documentation and the Take the vendor's policy designates. They are no longer read automatically: a newer Take may exist, check the release's documentation.

Read from the vendor's own documents by the collection described in this guide; the examples in the text are illustrative and dated, these facts are live.

Quantum Security Gateway

Product page

Recommended release for all deployments: R82.10

  • R82.20Latest public release —Vendor recommendation —Not collected
  • R82.10Latest public release —Vendor recommendation R82.10Not collected
  • R82Latest public release —Vendor recommendation R82 JHF Take 127Not collected
  • R81.20Latest public release —Vendor recommendation R81.20 JHF Take 170Not collected

Quantum Security Management

Product page

Recommended release for all deployments: R82.10

  • R82.20Latest public release —Vendor recommendation —Not collected
  • R82.10Latest public release —Vendor recommendation R82.10Not collected
  • R82Latest public release —Vendor recommendation R82 JHF Take 127Not collected
  • R81.20Latest public release —Vendor recommendation R81.20 JHF Take 170Not collected

Availability, recommendation and support are read from the vendor's documents and shown apart; a release Patcharo lists is not advice to install it.

Frequent mistakes

  • Recording a release without its Take, which makes the fix state of the device unknown.
  • Reading the recommended version of sk95746 as “the version every device must run now”: it is the recommendation for all deployments, not a statement about yours.
  • Taking the larger Take number as the first fixed Take when two documents disagree.
  • Treating the adoption level (Initial, Wide) as a recommendation of its own.

What to verify before acting

  • The release and the Take the device reports, as written in its installed packages.
  • The Take's entry in the release's Jumbo Hotfix Accumulator documentation: release date, adoption level, withdrawal notes.
  • The SK article of each vulnerability that concerns the device and the Take or hotfix it names for your release.
  • The support dates of your release in the Support Life Cycle Policy.

Sources

The official documents this guide rests on, read against the text on 19 Oct 2026. Nothing here is copied from them: read them for the authoritative wording.