Enterprise Adoption Guide: The Root Lock by HeartSuite Kernel in Regulated Environments

Overview: Practical guidance for CISOs and procurement teams adopting the HeartSuite kernel in regulated fleets — why the custom kernel exists, how vendor risk is owned, deployment and recovery patterns, and honest limitations including alternatives when a custom kernel is not acceptable.

Audience: Fortune 500 CISOs, procurement, risk, and compliance teams evaluating Root Lock by HeartSuite for production and regulated workloads.

Related reading: Start with the Procurement Brief (comparison table and decision guide) and Auditor Brief (threat model and residual risks). Cross-references throughout this guide point to the full set of kernel-hardening, security, operational, and comparison pages.

Why a custom kernel

Root Lock by HeartSuite uses a custom-built Linux kernel (based on mainline LTS releases such as 5.19.6 and 6.18) so that enforcement cannot be bypassed by an attacker who has already reached root.

The design removes at build time the kernel features most commonly used as bypass vectors for security controls:

• The BPF syscall (CONFIG_BPF_SYSCALL) — there is no eBPF layer an attacker can load programs into or unload.
• User namespaces (CONFIG_USER_NS) — no unprivileged fake-root environment for container escapes or privilege escalation.
• FUSE and OverlayFS — path-confusion and mount-based bypasses against VFS-level enforcement are unavailable.
• Competing LSM frameworks (AppArmor, TOMOYO, and runtime SELinux enforcement) and related policy engines — no parallel policy that can be set permissive or edited to weaken decisions.

Enforcement logic for program execution, file access, and outbound network connections is compiled into the kernel binary itself. Blocking decisions are consulted on every relevant operation; there is no runtime configuration file or agent that root can unload, kill, or reconfigure to disable protection.

This is distinct from “hardening mitigations” (stack canaries, allocator hardening, etc.). Those raise the cost of exploiting a memory bug. Root Lock by HeartSuite removes the primitives that let a compromised process escape its intended boundary in the first place. See the side-by-side scores and rationale in the Procurement Brief and the bypass table in How Root Lock by HeartSuite Compares.

The result is a deliberately smaller kernel (approximately 9 loadable modules versus thousands in a general-purpose distribution) whose configuration is published with a SHA-256 hash for independent verification.

What Root Lock by HeartSuite owns for kernel risk

Root Lock by HeartSuite treats the kernel as an integrated part of the delivered product, not a third-party dependency the customer manages in isolation.

• Update cadence and patching: Kernels are released as coordinated versioned bundles with the userspace components (daemon, Dashboard, tools, and installer). Updates follow the same maintenance window model as policy changes: boot the Non-HS kernel, apply the bundle, return to the HS kernel, and review. Public patch targets, notification channels, and version-string semantics are in the Kernel Support Policy. Supported distributions and validation tiers are in the Distro Compatibility Matrix.
• CVE handling: The Kernel Security Transparency page provides per-CVE status with technical rationale. Features compiled out produce “Not Affected” entries (the vulnerable code path is absent by design; no patch or policy change is required). For reachable code paths, Lockdown’s allowlist bounds post-exploitation impact: new programs cannot execute, mounts are refused, and changes to sealed configuration are blocked. Scores on HeartSuite are computed and published (many high/critical CVEs drop to 0.0 environmental score on HS deployments). Scanner and audit workflows are in CVE Hygiene for Scanners.
• Stack pairing and testing: The kernel is built, tested, and supported together with the matching userspace. The full enforcement contract (VFS hooks + Lockdown seal + allowlist) is validated across supported distributions.
• Support SLAs: Commercial subscription terms cover the integrated stack, including kernel-related incidents, coordinated updates, and guidance on deployment and recovery. Activation and support details appear in the Subscription section and your subscription agreement.

Deployment mitigations: hiding kernel details in practice

Enterprise teams do not want operators making daily kernel choices. The product and recommended deployment patterns are built to keep the kernel choice at image-build or initial-provision time.

• Cloud Path: Pre-configured instances on major providers (AWS, Google Cloud, Azure, DigitalOcean, Linode, and others) arrive with the HS kernel already installed and set as default. The Dashboard appears on first login with Phase 1 complete. Serial console access from the provider remains available for recovery.
• Golden image recipes and automated install: Use your existing Packer, Terraform, Ansible, or cloud-init pipelines to produce base images that include the Root Lock by HeartSuite install bundle. The installer sets the HS kernel as the GRUB default, performs the initial boot, and surfaces the Dashboard. Baseline allowlists can be pre-seeded for homogeneous fleets (see Alert Settings — fleet syslog, webhook, and central policy patterns).
• Hiding details from operators: After initial provisioning, day-to-day interaction is through the Dashboard or central automation. Kernel selection appears only in the documented Maintenance flow (when changes are required) and in the System Info Strip when running on the maintenance kernel. GRUB entries for the original distribution kernel are retained (split into Maintenance and vanilla entries, with Maintenance labelled as the Setup Mode destination) for the recovery path.

Official pre-built images in the major cloud Marketplaces are in active development and will further reduce the need for customers to assemble images. Until those listings are available, the golden-image + automated-install pattern delivers equivalent repeatability and auditability using the same tooling you already apply to other base OS images.

Secure Boot, firmware compatibility, and roadmap

Current status: HS kernel support for UEFI Secure Boot (including MOK enrollment on local hardware and provider-specific flows such as Azure Trusted Launch and GCP Shielded VMs) is incomplete. Deployments that require Secure Boot enabled for the HS kernel entry may need to enroll via MOK during installation or temporarily boot with Secure Boot disabled for the HS kernel while using the provider console or local management for the Non-HS kernel.

The original distribution kernel (Non-HS) retains its signing status and can be used for recovery and maintenance regardless of Secure Boot policy.

Roadmap: Signed kernel images, streamlined MOK tooling, and cloud-provider-specific runbooks (Azure, GCP, AWS) are prioritized work. Expanded test coverage for UEFI Secure Boot paths is tracked alongside the existing partial e2e validation. Customers evaluating platforms with mandatory Secure Boot should engage support for the current test status and any interim runbooks applicable to their cloud account or hardware.

The bypass-prevention properties (physical presence required for any recovery path) hold on both the HS kernel and Non-HS kernel; Secure Boot is an orthogonal boot-integrity control.

Compatibility and certification

Root Lock by HeartSuite is designed to coexist with the majority of enterprise infrastructure components that do not themselves depend on the disabled kernel features.

Works with (standard configurations):

• Local and cloud block storage (ext4, xfs, and provider volumes) for the root and data filesystems.
• Standard networking stacks and cloud provider vNICs / security groups (Root Lock by HeartSuite controls only outbound per-program destinations; inbound remains the responsibility of the OS firewall or cloud controls).
• SIEM / SOAR ingestion via the two syslog streams and webhook (see Alert Settings).
• Monitoring and status collection via ~/.cache/heartsuite/status.json (Ansible facts, Nagios, Zabbix, custom collectors).
• Container workloads with fixed pod sets established before Lockdown engages (see deployment notes in How Root Lock by HeartSuite Compares).
• EDR and observability via log forwarding (no on-host eBPF attachment or kernel-module agents are possible or required; enforcement events flow through the existing syslog channel).
• Vulnerability scanners and HIDS/FIM agents (run during Setup Mode so their programs and paths are reviewed and approved).

Requires the Non-HS kernel or a separate host (or alternative controls):

• Local execution of eBPF-based tools (Falco, Cilium Tetragon, bpftrace, etc.) — the BPF syscall is deliberately absent.
• Dynamic Kubernetes environments with frequent pod creation, HPA scale-out, or rescheduling after Lockdown (mount operations required for new containers are refused).
• KVM hypervisor hosts (KVM host-mode features are compiled out).
• Rootless / unprivileged user-namespace containers.
• Any workload or tooling that explicitly requires one of the compiled-out features for its core function.

Decision tree (high level)

Full compatibility notes and known non-fits live in How Root Lock by HeartSuite Compares (section “Where a separate kernel is required”) and the system-requirements pages. As more storage, networking, EDR, and monitoring vendors publish explicit coexistence statements, this section will be expanded with a published matrix.

Operational model for fleets

The HS kernel is managed the same way you manage base OS images and policies — through the control planes you already own.

• Image lifecycle: Treat the HS kernel + baseline allowlist as part of your golden image. Packer templates call the official install bundle, pre-seed policy via the batch tools, and produce an image that boots directly to the protected state. Reprovision or patch images on the same cadence as your other distributions.
• Provisioning: Terraform, cloud-init, or your IaC tool launches the image (or runs the installer non-interactively). No special kernel module or agent is required after boot.
• Policy at scale: Allowlist content (programs, file paths, network destinations) is curated centrally and applied via Ansible, Terraform + GitOps, ServiceNow, or custom automation exactly as described in Alert Settings (fleet export surfaces and central policy patterns). Pre-seeding accelerates homogeneous fleets; observation + central review handles varied workloads.
• Kernel updates: Delivered as versioned bundles. Apply during planned maintenance windows using the standard Non-HS kernel path (or by reprovisioning from an updated golden image). The Dashboard and automation surfaces make the required steps repeatable.
• Observability and drift: status.json, the JSONL approval log, and the two syslog streams feed your existing fleet dashboards and SIEM. Drift detection (policy or mode) is performed by harvesting from central jobs and comparing against the Git/CMDB source of truth.
• No new kernel-specific fleet tooling: The same rsyslog rule, SSH/Ansible access, and image pipeline you use today handle the kernel boundary.

This model keeps ownership of policy curation, change records, and visibility inside the tools your teams already run.

Risk transfer under commercial subscription

A commercial subscription for Root Lock by HeartSuite covers the full delivered stack, including the kernel:

• Vendor support and SLAs for incidents, updates, and deployment guidance that encompass kernel behaviour.
• Contractual risk-transfer terms (indemnification and liability provisions) as set out in the subscription agreement for the licensed software.
• Access to the verification artifacts published on this site (config hashes, evidence packs, CVE transparency data) that support customer and auditor due diligence.
• Coordinated release process so that kernel changes, userspace changes, and documentation remain in sync.

The kernel does not carry a separate support contract or separate risk posture; it is part of the integrated product under the same subscription that enables Lockdown. Details of indemnity scope, SLA commitments, and verification deliverables are in your specific subscription agreement. See the Subscription page for activation mechanics.

Supply chain transparency and integrity

• Reproducible posture verification: Every released HS kernel includes a published SHA-256 of its exact .config file. Any team can obtain the config from the kernel package and re-run the open-source kernel-hardening-checker to reproduce the exact attack-surface and exploit-resistance scores shown in the Procurement Brief and Auditor Brief. See evidence-pack-*.txt files for raw output.
• Installer and bundle integrity: Distributed bundles include SHA-256 manifests (.sha256 files) for verification before execution.
• SBOM and provenance: A full software bill of materials covering the kernel and userspace components, plus expanded reproducible-build artifacts and signing for kernel binaries, is in active development. Current customers receive the available verification material (config hash + evidence packs + bundle hashes) under their subscription; additional supply-chain artifacts are provided on request or as they become available. Public roadmap and interim controls: Supply Chain and Advisory Feeds. Per-stream evidence publication: Evidence Status.
• No reliance on opaque vendor claims for the measured hardening posture: The numbers are tool outputs against public hashes.

Recovery and fallback: the Non-HS kernel as supported escape hatch

Every installation retains a first-class recovery path:

• The original distribution kernel is always present in GRUB (split into Maintenance and vanilla entries during install, with Maintenance labelled as the Setup Mode destination).
• The Dashboard’s Maintenance flow ([m]) detects Lockdown state and guides the operator through the exact sequence: reboot to Non-HS kernel, remove the immutable seal, make changes, reboot back to the HS kernel, review new activity, and re-engage Lockdown.
• The Dashboard’s Maintenance ([m]) handles the common case of quick Non-HS work followed by guided return to the Root Lock by HeartSuite kernel and review.
• For policy or platform conflicts that make the Root Lock by HeartSuite kernel unsuitable for an extended period, teams can remain on the maintenance kernel (the product continues to run and log in non-enforcing mode) or remove Root Lock by HeartSuite entirely. Both paths are supported and documented.
• Physical or console access (local keyboard/monitor, serial, or cloud provider serial console) is always sufficient to select the Non-HS kernel and regain full control. No software on the system can block this path.

This is the documented, supported escape hatch for operational needs, kernel policy conflicts, or environments that ultimately decide against a custom kernel. Full procedures appear in the Maintenance section and FAQs.

Evidence and independent verification for customers and auditors

Nothing on the kernel posture page relies on “trust us.”

• Reproduce hardening measurements yourself with the published config SHA-256 and the open-source checker (full commands in Auditor Brief).
• Review every relevant CVE with the exact “Not Affected / Score on HeartSuite 0.0 / bounded impact” rationale on the Kernel Security Transparency page.
• Inspect live state via the status JSON, per-decision syslog events, approval log, and the sealed allowlist files (all readable or harvestable without special privileges beyond normal admin access).
• For procurement and audit packages: the Procurement Brief, Auditor Brief, comparison matrix, and evidence packs are self-contained artefacts that can be attached directly to RFPs, due-diligence questionnaires, and auditor workpapers.

Honest limitations

Root Lock by HeartSuite with the HS kernel is a deliberate architectural choice that trades general-purpose kernel compatibility for bypass resistance and root-immunity. It is not the right fit for every environment.

Organisations with formal “no custom kernel,” “no modified kernel,” or “vendor-certified kernel only” policies (driven by support contracts, regulatory certification of the base OS, or internal change-control mandates) should not adopt the HS kernel.

In those cases the supported path is:

• HeartSuite Joint File System (HJFS) — a filesystem-based enforcement layer that provides per-program, per-version file isolation and automatic backup/rollback on a completely standard kernel. No kernel replacement is required. HJFS is deployable on cloud instances where the kernel is provider-managed and on systems under strict kernel certification rules. See the full HJFS documentation (overview, deployment scenarios, limits, and how it complements execution/network controls).
• Layered controls on the standard kernel (SELinux or AppArmor in enforcing mode, seccomp filters, eBPF-based detection where needed, network egress filtering, EDR, vulnerability management, and HIDS). Root Lock by HeartSuite’s execution and network gating concepts are not applicable without the HS kernel.
• Where both file isolation and execution/network gating are required under a no-custom-kernel constraint, HJFS plus existing or companion execution/network tooling (including HeartSuite Exec Lock in some configurations) is the evaluated combination.

The HJFS how-it-compares and limits pages, together with the bypass and circumvention sections of How Root Lock by HeartSuite Compares, give procurement teams the material needed to map requirements to the appropriate product or combination.

Root Lock by HeartSuite positions the HS kernel for the subset of workloads where the documented properties (compiled enforcement, physical-presence recovery only, bounded CVE impact via compiled-out features and Lockdown) justify the kernel change.

Next steps for enterprise evaluation

1. Read the Procurement Brief decision guide and run the published measurements on a test deployment.
2. Review the Auditor Brief and the full CVE transparency page.
3. Pilot using a cloud pre-configured instance or a Packer-built golden image on a non-production workload.
4. Map your compatibility requirements against the decision tree and the “where a separate kernel is required” section of How Root Lock by HeartSuite Compares.
5. For platforms with Secure Boot or Marketplace requirements, request current runbook and timeline status from support.
6. For strict no-custom-kernel policies, evaluate HJFS in parallel.
7. Engage commercial discussions for subscription terms, support SLAs, and any additional verification artefacts.

The kernel is one component of a larger control. The surrounding pages (central policy management, SIEM integration, maintenance, and comparison material) describe how the rest of the operational model fits into an enterprise security program.

This page is intentionally buyer- and auditor-facing. All posture claims reference publicly reproducible artefacts or the open CVE transparency data. Last updated: 2026-06-16.