Yes, but plan for it. CMake's FETCHCONTENT_FULLY_DISCONNECTED stops downloads, yet its documentation warns it is not a way to block network access on a first run. Mirror sources internally, pin by hash, and record the resolved versions, so an offline build is repeatable and auditable.
What the CMake documentation says
FETCHCONTENT_FULLY_DISCONNECTED is off by default. When on, no attempt is made to download or update any content. The page warns that it is not an appropriate way to prevent any network access on the first run in a build directory, because it is meant to be turned on after CMake has already run once and populated the content.
A related note: with updates disconnected, switching to an unknown commit hash will fail, which is what you want in a controlled environment.
Why teams build offline
- Air-gapped or restricted build networks.
- Reproducibility: the same inputs on every run.
- Resilience when a host disappears or a tag is removed.
- A security control: no build step reaches the internet.
A workable design
- Mirror every source you use, whether Git repositories or archives, into storage you control. Treat the mirror like any other asset with access control.
- Point FetchContent declarations at the mirror and pin them by commit hash or URL_HASH. See how to verify a downloaded library in CMake.
- Populate a build directory once on a connected, controlled machine.
- Move the populated sources into the offline environment, or let the offline build pull from the mirror.
- Turn on the disconnected option in offline runs so a missing source is an error instead of a silent download attempt.
For package managers the same idea applies. Conan and vcpkg both have local or file-based caches and binary sources, so an internal cache can serve builds with no external access.
Keep the version record
Offline does not mean unaware. Each build should write down what it used:
| Record | Where it comes from |
|---|---|
| Library name and version | Your pins, lockfile or manifest |
| Commit hash or archive digest | The CMake declaration |
| Mirror snapshot date | Your mirror process |
| Build identifier | CI |
Put these into the SBOM for the release. Then when an advisory arrives, you can answer from records instead of rebuilding in a hurry.
The update problem
An offline build never updates by itself. Schedule a regular connected refresh: fetch new releases to the mirror, review the diff, update pins, and run the offline build again. Without it, the mirror becomes a time capsule of vulnerabilities.
Quick check
Does the disconnected option prevent a first download?
No. The documentation says it is not suitable for blocking network access on a first run. Use it after the content is populated.
Does offline building improve security?
It removes one risk, a build that fetches changed content. It adds the duty to refresh and review your mirror.
Safeguard's SBOM and dependency scanning can build an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Sources
Last reviewed: 19 October 2026.
