Why endpoint monitoring for air-gapped networks is a different build
An air-gapped enclave changes the build before any tool is chosen. Endpoints and servers in these networks have no internet path, so every agent package, Wazuh release, detection rule, vulnerability dataset and Velociraptor artifact must cross the boundary by controlled media transfer. The short answer for most teams is Wazuh for agent-based detection, software inventory and vulnerability correlation, with Velociraptor for hunting across hosts and offline collection where an agent cannot be installed. The isolation boundary, not the feature list, determines how each component is installed, updated and verified. Wazuh documents an offline installation guide for systems without internet connectivity, and its vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Velociraptor's server is typically deployed on a cloud virtual machine, which the enclave may not allow, so the server placement is a first decision to confirm.
The enclave also moves where telemetry lives and who can reach the console. Wazuh stores alerts in its indexer, and Velociraptor keeps its data in files on the server filesystem, so both platforms place endpoint evidence inside whatever storage and backup boundary you define. Confirm where the indexer, the Velociraptor data directory and the backups sit, who holds administrator roles on the dashboard and GUI, and whether the console is reachable only from an approved management zone. Those answers drive access control, audit logging and retention, and they are the points your auditors and the authority to operate will ask about first.
Plan the media transfer as a repeatable process, not a one-time copy. Each update to Wazuh, Velociraptor, rules, decoders and vulnerability data must be checked for integrity and authenticity before it is introduced, which is the same kind of supply chain control that NERC CIP-013-2 describes for vendor software and patches. Ask your implementation partner to document the transfer chain, the verification steps, the rollback path and who approves each import. Also confirm licensing for your edition and deployment model, since offline support is sometimes a paid-tier feature on other vendors' products and must be checked for each component in your stack.
Which requirements shape an air-gapped endpoint monitoring design
This table maps the supplied regulatory requirements to concrete design choices for offline media, console access and log retention inside the enclave. Read each row as a question to answer in your own environment, and treat the sector rows marked as unconfirmed as items for counsel or your auditor to settle.
| Requirement | What it asks for | Build decision inside the enclave | Where it usually fails |
|---|---|---|---|
| HIPAA 45 CFR 164.312 access control and unique user identification | Access control with unique user identification for systems holding ePHI | Give every Wazuh dashboard and Velociraptor GUI user a named account, with no shared administrator login, and keep the account list under change control | Shared console accounts reused across shift staff and offline collector operators who are not individually recorded |
| HIPAA 45 CFR 164.312 audit controls | Mechanisms that record and examine activity in systems containing ePHI | Send Wazuh alerts and Velociraptor audit records to a log store inside the enclave, and define who reviews them and how often | Audit logs kept only on the console host, with no review owner and no retention rule |
| FTC Safeguards Rule 16 CFR 314.4 multi-factor authentication | MFA for any individual accessing an information system, as applied to in-scope financial institutions | Require MFA for dashboard and GUI logins, and decide how offline staff authenticate when no identity provider is reachable | Local accounts with passwords only, added during an outage and never removed |
| FTC Safeguards Rule 16 CFR 314.4 encryption and activity logging | Encryption of customer information in transit and at rest, and logging of authorized user activity | Encrypt the Wazuh indexer and Velociraptor data directories at rest, and log administrator actions on the console | Telemetry copied to removable media in plain form and not tracked after transfer |
| NERC CIP-013-2 software integrity and authenticity | Supply chain processes that verify integrity and authenticity of vendor software and patches | Verify checksums and signatures on every package, rule set and artifact before it crosses the boundary, and record the verification on the transfer log | Packages verified once at the source but not re-checked after transfer through a review station |
| NERC CIP-005-7 interactive remote access | Remote access to high or medium impact systems through an Intermediate System with encryption and multi-factor authentication | Route any remote console or vendor support session through a controlled intermediate host, with MFA and session detection, if the enclave holds in-scope systems | Vendor laptops connected directly to the console network during maintenance windows |
| NERC CIP-005-7 vendor session detection | Methods to detect and disable active vendor remote access sessions | Log vendor session starts and ends on the intermediate host, and define the procedure for ending a session | Sessions left open after work finishes with no alert or owner |
| Sector rules not supplied for this page | Retention periods, evidence formats and review cadence vary by regulator and contract | Confirm retention length, log format and review frequency with counsel and the auditor before fixing storage sizes | Assuming a generic retention period that a regulator or contract does not accept |
Which open-source platforms fit an air-gapped enclave and why
An enclave changes what a platform must do without a connection: install from media, refresh vulnerability and detection content by transfer, and keep telemetry inside the boundary. The cards below cover the endpoint and network components that most often appear in these designs, with the checks to run before you commit to each one.
Wazuh as the endpoint and log core
Wazuh is distributed under GPL-2.0 and has four components: the Wazuh indexer that stores alerts, the Wazuh server that applies decoders and rules, the Wazuh dashboard and the agents on endpoints. Its offline installation guide covers systems without internet connectivity. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and devices such as firewalls can be monitored without an agent through syslog collection. Confirm that each legacy host in the enclave is on the agent support list, and plan for agentless collection where it is not.
Offline vulnerability data for Wazuh
Wazuh vulnerability detection correlates the software inventory that agents collect with vulnerability data from either the Wazuh Cyber Threat Intelligence platform or an offline vulnerability repository. In an enclave, the offline repository is the path that matters. Someone must build it outside the boundary, move it across on approved media, load it into the server and record the import date. Ask whether your security team will own that cycle or whether a partner will run it, because a stale repository quietly ends detection of newly published flaws.
Velociraptor for hunting and collection
Velociraptor is licensed under AGPL-3.0 and ships as a single statically compiled Go executable. It needs no separate database because the server keeps data in files on its filesystem. Offline collectors, built from the GUI, have the capabilities of a normal client, can run any artifact and write results to JSONL or CSV, which suits hosts where no client can be installed. Its server is only fully supported on Linux, so confirm that the enclave can host a Linux server and that your team can operate it.
Artifacts authored and reviewed inside the enclave
Velociraptor collects host state with VQL queries usually wrapped in artifacts, which are YAML files stored on the server. Analysts can view, modify and add artifacts in the GUI without rebuilding clients or servers. This removes the need to fetch new detection logic from the internet, but every artifact is code that runs on your endpoints. Set a review and approval step for changes, keep a versioned copy of the artifact set, and confirm that imports are handled through the same media process as other content.
Security Onion for network-side visibility
Security Onion is a network-side complement to endpoint tooling. Its ISO carries packages along with NIDS, YARA and Sigma rules for full installs without internet access. Its soup tool updates an installation from newer ISO media in airgap mode. It is licensed under the Elastic License 2.0, which you should review against your own distribution and internal use plans. Use it to watch traffic between enclave zones, and confirm that sensor placement and storage fit the enclave's network design.
Licensing for air-gap features
Air-gap support is a paid feature for some vendors in adjacent tools. Mattermost lists air-gapped deployment in its Enterprise Advanced tier, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Confirm in writing, for every component in your stack, whether offline installation, offline updates and offline support are included in the license you will run. Do not assume that an open-source core carries those rights, and record the answer as part of the bill of materials.
How an air-gapped Wazuh and Velociraptor rollout runs in phases
The sequence moves from a verified inventory of the enclave to a dated evidence pack that shows the Wazuh and Velociraptor stack works without internet access, with every transferred file checked on arrival.
Inventory the enclave and its boundary
DeployOpen works with your security and operations teams to list every server, endpoint and network segment inside the enclave, the operating systems and versions on each, which hosts can accept an agent, and which must be monitored through logs or an offline collector. The boundary is documented: what crosses it, by which media, and who approves each transfer. The output is a signed scope document and an endpoint register. You provide system owners, asset data from your CMDB or existing scanners, the change approval path, and the names of people authorized to handle media.
Stage packages and define the media transfer procedure
DeployOpen prepares the installation bundles for the Wazuh components, the Velociraptor binaries and server, the offline vulnerability repository, and rule and artifact updates from a staging network that has connectivity. Each file is recorded with a cryptographic hash and a manifest, and the transfer procedure defines how media are created, scanned, labeled, carried across the boundary and verified on arrival. The output is a transfer runbook and a hashed manifest that your reviewers can check independently. You provide the approved media types, scanning tools and the data classification rules that govern what may cross.
Install Wazuh and the Velociraptor server offline
Inside the enclave, the team installs the Wazuh indexer, server and dashboard following the offline installation guide, and deploys the Velociraptor server on Linux, which the Velociraptor documentation identifies as the fully supported server platform. Container images or Kubernetes components, where used, are pulled into a private registry in advance. Each component is confirmed to start, to hold its own data locally and to reach no external endpoint. The output is a build record listing versions and hashes, and a network capture showing no outbound connections. You provide the hardware or virtual machines, storage sized to your retention requirement, and the administrator accounts.
Deploy agents and offline collectors
Wazuh agents are installed on supported endpoints through your existing software distribution tool, and enrolled with the Wazuh server. Velociraptor clients are deployed where possible, and offline collectors built from the GUI cover hosts where a client cannot be installed, writing results to JSONL or CSV for transfer back to the enclave review workstation. Agent configuration, groups and collection policy are set centrally. The output is an enrollment report showing which endpoints are reporting, which are not, and why. You provide change windows for endpoints, approval for each agent version, and the owners of systems that tolerate no software changes.
Run the offline vulnerability and rules update cycle
Vulnerability detection uses the offline repository in place of the Wazuh CTI platform, and detection rules, decoders, Velociraptor artifacts and any Sigma content are refreshed by new media transfers on a schedule your change board approves. Each update is staged, hashed, imported into a test instance first, and then promoted. The output is an update log that records what changed, when it was imported and who approved it. You provide the update cadence, the approver, and the decision on which external intelligence feeds, if any, are permitted into the staging network.
Test acceptance and assemble the dated evidence pack
DeployOpen tests the deployed stack against the agreed scope: agent reporting on each endpoint class, a detection test using a benign simulated event, a Velociraptor hunt across a sample of hosts, an alert forwarded through the dashboard, a restore from backup, and a check that no outbound traffic occurs. Results are compared with the acceptance criteria written in phase one. The output is a dated evidence pack with configuration exports, hash manifests, test records, the network observation and the approved update log. You review and sign acceptance. The pack supports your own assessments, and DeployOpen does not issue audit opinions.
What changes in storage, updates and remote access inside the enclave
Inside an enclave, the operational burden shifts from the vendor's cloud to your own storage, your own update pipeline and your own access controls. Wazuh stores alerts in the Wazuh indexer, a full-text search and analytics engine that you host, so disk sizing, index retention and snapshot backups are decisions you own. Velociraptor works differently: its server keeps data in files on its filesystem and needs no separate database, so the storage design is a filesystem design. Confirm with each vendor how their backup and restore procedures work with air-gapped media, and test a restore inside the enclave before you rely on it. Plan retention periods with your compliance lead, since they determine how much local media you need to hold.
Updates are the step most often underestimated. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months, and Wazuh 4.14.9 was released on 14 October 2026. Each release has to be copied across the boundary, checked for integrity and staged in a test enclave before production. Velociraptor 0.77.3 was released on October 5, 2026, and its documentation asks users to update to that release to address multiple CVEs, so a security-driven update may arrive out of cycle. If the platform runs on Kubernetes, the kubeadm pattern applies: kubeadm config images list and kubeadm config images pull fetch control plane images in advance, and --image-repository points kubeadm init at a private registry. Agree a written update cadence and an emergency path with your partner before go-live.
Remote vendor and engineer sessions into this environment are a compliance question as much as a technical one. NERC CIP-005-7 requires that all Interactive Remote Access to high and medium impact BES Cyber Systems pass through an Intermediate System with encryption and multi-factor authentication, and that you have methods to detect and disable active vendor remote access sessions. If you are not an electric utility, use the same pattern as a design baseline: one controlled access point, strong authentication, session visibility and a documented kill switch. Pair this with supply chain controls under NERC CIP-013-2, which address verifying the integrity and authenticity of vendor software and patches. Ask your implementation partner how they will bring in updates, who can open a session, and how each session is logged and ended.
What auditors and regulators ask for from an air-gapped monitoring system
How do I show unique user identification and access records for Wazuh and Velociraptor?
Each administrator should log in with a named account, and the platform should record who did what. Wazuh keeps its own audit trail of dashboard and API activity, and Velociraptor records actions taken in its GUI and API, including artifact collections and hunts. Auditors typically want these records exported to a location the administrators cannot edit, and they want a sample reconciled against the account list. Confirm with your platform team how each component logs authentication and whether logs forward to an enclave-local store. Under the HIPAA Security Rule at 45 CFR 164.312, unique user identification and audit controls are explicit technical safeguards, so this evidence maps directly to that requirement. DeployOpen prepares the evidence and configuration, but auditors issue any opinion on whether it is sufficient.
What activity logs must I keep for authorized users on an isolated network?
You need records of logins, privilege changes, configuration edits and monitoring actions performed by authorized users. In this design, Wazuh records administrative and rule changes on the server and indexer, while Velociraptor logs hunts, collections and artifact changes. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users, so these logs are often the first thing examiners request. Define a retention period with your compliance team, and confirm that logs from both platforms land inside the enclave with timestamps synchronized to an internal time source. DeployOpen can configure log export and document the retention settings, and your auditors decide whether coverage meets your obligations.
How do I prove that packages carried across an air gap were not altered?
Record a cryptographic hash and the source of every transferred file, then verify it again on arrival inside the enclave. Each transfer should have a manifest listing package names, versions, hashes, the person who approved the transfer and the date. Verification should be repeated before installation, and failed checks should be logged and escalated. NERC CIP-013-2 requires supply chain processes to address verification of software integrity and authenticity for vendor software and patches, which is the control behind this check. Confirm with your procurement or grid compliance team which verification method and signing keys they accept. DeployOpen can script the manifest and verification steps and prepare the procedure documents, while the auditor evaluates whether the process is adequate.
What evidence shows that offline vulnerability data is current?
Keep a dated record of each vulnerability data import, the source it came from, and the hash of the file imported. Wazuh vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform, so the import log and the repository version become the evidence of currency. Show the time between each import and the most recent vendor release you were able to obtain, and document any gaps with the compensating controls you used. Auditors usually look for a defined update cadence and proof that it was followed, not perfect freshness. Confirm the update cadence with your security governance team before you set a target. DeployOpen can build the import workflow and reporting, and the cadence itself is your decision.
Where is endpoint telemetry stored, and how long is it kept?
In an air-gapped design, telemetry should be stored only inside the enclave, on storage you control, with retention rules written down and enforced. Wazuh stores alerts in its indexer, and Velociraptor keeps its data in files on the server filesystem, so both locations should be named in the system security plan. Auditors typically ask for the retention period, the storage location, who can access the data and how deletion is recorded. Confirm with your legal and records teams what period applies to your sector, because regulators set different minimums. DeployOpen can configure storage paths, access controls and retention settings, and can document them for assessment.
How are endpoint collections preserved so their integrity can be shown later?
Preserve each collection with its original output, a hash, the artifact definition used, the collector identity and the time of collection. Velociraptor offline collectors can write results to JSONL or CSV, and the export package should be hashed and stored in write-once or access-restricted storage. Keep a chain-of-custody log that records each person who handled the data and each transfer inside the enclave. Confirm with your incident response counsel what format and handling your insurers, regulators or law enforcement expect, since those requirements vary. DeployOpen can set up collection handling and document the procedure, while the adequacy of evidence is determined by the parties receiving it.
Can DeployOpen certify that our air-gapped monitoring meets an audit?
No. DeployOpen plans, implements, hardens and documents the monitoring system and prepares the evidence an assessor will request, including configuration records, logs, procedures and test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before scoping the work, ask your assessor which evidence formats they accept and which controls they expect to test. Scope, deliverables and timelines are agreed in writing before work starts, so the evidence list can be fixed in the statement of work.
What to ask an implementation partner before an air-gapped build
Start by asking the partner to show, in writing, how an offline installation of Wazuh and Velociraptor is performed in a network that matches yours. Ask which installation path they will follow, such as the Wazuh offline installation guide, and what they will stage in advance: packages, container images, agent installers and documentation. Ask how the Velociraptor server will run in the enclave, since Velociraptor's documentation says the server is only fully supported on Linux, and confirm the exact operating system and version they will certify for your environment. Ask who holds administrator access to the Wazuh indexer, server and dashboard, to the Velociraptor GUI and to the operating systems beneath them, and how those roles are recorded and reviewed.
Next, ask how every file that crosses the boundary is verified. A strong answer names the checksum or signature method for each package, the media log that records who carried what and when, and a second-person review before import. Ask how offline vulnerability data is refreshed for Wazuh vulnerability detection, how often the partner expects to do this, and how Wazuh rules, decoders and Velociraptor artifacts are reviewed before they reach production. Ask for the same answers for Security Onion's soup updates if it sits in the same enclave. For licensing, request a component-by-component list covering Wazuh under GPL-2.0, Velociraptor under AGPL-3.0 and any other tool in the design, with each license's obligations for your use. Confirm that the list is independent of any vendor edition pricing.
Finally, request a written scope with a fixed deliverable list. It should name the backup method and schedule for indexer data, server configuration and Velociraptor data, where restore copies are stored inside the enclave, and how a restore is tested. It should also state what happens when a hotfix such as a CVE-driven Velociraptor update must cross the boundary. Ask who signs off each deliverable and which items are one-time (installation, hardening, documentation) and which recur (media transfers, rule and artifact updates, backup tests). Ask for these items in the quote so that the cost of the recurring work is visible before the build begins. Confirm the scope, deliverables and timeline in writing before any work starts.
How much does an air-gapped endpoint monitoring build cost and what does it need from us?
What drives the cost of an air-gapped Wazuh and Velociraptor build?
The main cost drivers are endpoint count, server and storage sizing, the media transfer process, the offline vulnerability workflow and detection tuning. The software itself is open source, so the spend goes to infrastructure, engineering labor and ongoing operations. Wazuh is distributed under GPL-2.0 and Velociraptor under AGPL-3.0, so neither carries a per-endpoint license fee to pay for the build. Ask any quote to break out hardware, implementation, documentation, and recurring update work separately, so each driver can be tested against your own enclave.
Can our own team deploy air-gapped endpoint monitoring without outside help?
A team with Linux administration, Windows endpoint management and a clear change process can deploy it internally, because Wazuh documents an offline installation guide and Velociraptor offers offline collectors built from its GUI. The harder parts are usually not the installers. They are building a trusted transfer path for packages and rules, keeping an offline vulnerability repository current, sizing the indexer, and tuning detections so analysts trust the alerts. Organizations often decide based on how many people can own these tasks after go-live, and that answer should appear in any scope agreement.
How long does it take to reach a working air-gapped build?
The timeline depends on scope, including how many enclaves are involved, how many endpoint types need coverage, whether staging hardware exists, and how long your approval and media-handling process takes. No general duration is supported by the sources used for this page, so do not accept a schedule that is not written against a defined scope. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ask for milestones tied to a pilot enclave and a documented acceptance test.
What do we need to provide before an air-gapped monitoring project starts?
Prepare an inventory of the enclave boundary, the list of systems and endpoints in scope, the network segments and their allowed flows, and the approval path for bringing software and data across the boundary. You will also need staging hardware or virtual machines that match the target sizing, and a named owner for media transfers. Confirm which operating systems and legacy hosts are present, since agent support varies by platform. The clearer this inventory, the fewer assumptions a quote has to carry.
Which costs are one-time and which recur in an offline monitoring program?
One-time work includes architecture, the initial offline installation, staging, agent rollout across the estate, documentation and the first set of detection and dashboard tuning. Recurring work follows the vendor release cycle and your own process. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so the update cycle is a steady operating task. Each update, rule set, vulnerability feed and Velociraptor artifact update must be validated, packaged, transferred and tested. Ask a partner to price these cycles separately, and to say whether they are included in a retainer.
How does the media transfer process affect the effort and the risk?
Every update crosses the boundary on approved media, so the transfer process sets much of the recurring effort. Each cycle includes packaging, hashing, malware scanning, approval, import and verification. NERC CIP-013-2 requires supply chain procurement processes that address verification of software integrity and authenticity for vendor software and patches, which is the reason many organizations verify every package before it enters. Confirm how many transfer cycles per month your change board allows and who signs off, because that determines how often the enclave can be patched.
Does offline vulnerability data cost more to maintain than online feeds?
It adds recurring work rather than a license fee. Wazuh vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform, so the enclave must receive a current copy of that data through the transfer process. The effort depends on how often you refresh it, how many systems depend on it, and how you prove the data was current at a given date. Ask for the refresh cadence, the staging and checksum steps, and a method for showing which feed date each alert was based on.
Why does detection tuning change the cost of an air-gapped deployment?
Tuning drives the amount of analyst time needed after go-live, because an offline environment has no fast external feed to fall back on when rules are noisy. Expect work on decoders, rules, suppression lists, file integrity settings and Velociraptor artifacts for each host type. Velociraptor artifacts can be modified in the GUI without rebuilding clients or servers, which keeps tuning inside the enclave. Ask a partner how many tuning cycles are included in the build, and how they will document each change for auditors.
Does air-gapped support require a paid edition of the monitoring tools?
For Wazuh and Velociraptor, the sources used here describe open-source licenses and documented offline procedures, so the core tools do not depend on a commercial tier to run offline. Other vendors do gate air-gapped deployment behind paid editions, including Mattermost Enterprise Advanced, Metabase Enterprise and Element's Sovereign edition, so the licensing question is different for each product in your stack. Confirm the license for every component you plan to add, including any commercial threat intelligence, storage or support subscription, before you finalize the budget.
How DeployOpen scopes and supports air-gapped endpoint monitoring
Air-gapped endpoint monitoring fails most often at the edges: what gets installed, how updates cross the boundary, and who keeps the evidence current. DeployOpen covers those edges through written scope, deployment inside your enclave, testing of the stack, and evidence preparation that your own assessors can review.
Fixed scope agreed in writing
Before any work starts, the engagement defines which endpoint operating systems, server roles and legacy hosts are covered, which Wazuh and Velociraptor components run in the enclave, and which offline update paths are approved. Scope decisions are the cheapest point to resolve questions about unsupported systems or hosts that cannot take an agent. Check that the written scope names the deliverables, acceptance criteria and the people who sign off on each one.
Deployment inside your enclave
DeployOpen installs the Wazuh server, indexer and dashboard, and the Velociraptor frontend, in your own data center or isolated cloud accounts, using installation sources that you can carry across the boundary. The work includes preparing the offline package set, the container or Kubernetes images where used, and the internal time and certificate services the stack depends on. Confirm where the telemetry and backups physically reside before deployment begins.
Update cycle by media transfer
An air-gapped monitoring stack stays current only if rules, decoders, vulnerability data and Velociraptor artifacts reach the enclave on a repeatable schedule. DeployOpen designs the transfer procedure, the staging and hash verification steps, and the rollback plan for each cycle. Ask who approves each import and how the chain of custody is recorded, because your supply chain controls will examine that record.
Hardening and testing the monitoring stack
The monitoring platform is itself a high-value target because it holds telemetry from every enclave host. DeployOpen hardens the server, indexer and dashboard, restricts administrative access, and tests the deployment, including whether agents still report and alerts still fire after an update. Ask for the test results and the remediation list, and confirm whether testing covers the monitoring components as well as the endpoints they watch.
Documentation and evidence preparation
Assessors will ask how each control was implemented, how changes were approved and what the logs show over time. DeployOpen prepares the architecture records, runbooks, access lists, update logs and retention settings that your compliance team can present. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications. Confirm with your auditor which artifacts they accept before the evidence set is defined.
Retainers for ongoing update cycles
Wazuh and Velociraptor release updates on their own schedules, and each release may need a new offline package, a tested upgrade and a documented change record. DeployOpen offers ongoing support and upgrade retainers that run these cycles, along with periodic testing of the stack. Ask for the response expectations, the upgrade windows and how security fixes that arrive mid-cycle are handled before you sign.

