Alerts when Lockdown blocks something

• 1: Pipe Lockdown blocks into the SIEM you already run
• 2: Drive the allowlist from your own tooling

journalctl -t heartsuite --since "1 minute ago"

:programname, isequal, "heartsuite" @@your-siem-host:514

{
  "node_id":            "prod-web-03",
  "event_type":         "new_program_blocked",
  "timestamp":          "2026-03-31T14:22:00Z",
  "mode":               "Secure Mode",
  "lockdown":           true,
  "tier":               2,
  "paths":              ["/tmp/dropper", "/tmp/payload"],
  "count":              2,
  "message":            "2 previously unseen programs blocked.",
  "subscription":       "Active",
  "total_pending":      2,
  "pending_programs":   2,
  "pending_file_r":     0,
  "pending_file_w":     0,
  "pending_network":    0,
  "enrich_failed":      false
}

1 - Pipe Lockdown blocks into the SIEM you already run

Overview: Root Lock by HeartSuite integrates with your existing SIEM, EDR, and observability stack via syslog (journald/rsyslog) and webhook. Configure once in Alert Settings → Fleet, and let your central tooling handle monitoring, correlation, and alerting. There is no requirement to run the Dashboard on every host for day-to-day fleet visibility.

Root Lock emits kernel denial decisions and higher-level alerts in real time. Allowlisted work that succeeds is not streamed, so every event your SIEM receives is either a denial or an alert.

Syslog (recommended for SIEM ingestion)

When the Fleet tab Syslog switch is on (Send alerts to /dev/log (LOG_AUTH facility)), every alert and every kernel denial is written to the local journal under identifier heartsuite. Alert message text begins with heartsuite-alert:.

Filebeat / Elastic (or any rsyslog-compatible shipper)

# filebeat-heartsuite.yml (adapt to your existing stack)
filebeat.inputs:
  - type: journald
    id: heartsuite-enforcement
    include_matches:
      - "SYSLOG_IDENTIFIER=heartsuite"
output.elasticsearch:
  hosts: ["https://your-elastic:9200"]
  # username, password, ssl.* etc. from your existing config
logging.level: warning

The journal identifier is heartsuite on every host. How you ship that identifier is stack-specific: Filebeat journald for Elastic, a universal forwarder or HEC for Splunk, a DSM for QRadar, promtail for Loki. The YAML above is an Elastic example, not a universal ingest path.

Pre-flight check on the host:

filebeat test config && filebeat test output

Direct rsyslog forwarding

Create /etc/rsyslog.d/heartsuite.conf:

:programname, isequal, "heartsuite" @@your-siem-host:514
# Use @ for UDP or the TLS modules for production

Then:

sudo systemctl restart rsyslog
journalctl -t heartsuite --since "1 minute ago"

Webhook (for PagerDuty, OpsGenie, Slack, etc.)

Enter an HTTPS URL in Webhook URL (must be HTTPS) on the Fleet tab. Root Lock posts a JSON payload on every alert (immediate delivery, no batching — let your receiver deduplicate). HTTP (non-TLS) URLs are rejected. When the URL contains pagerduty.com or opsgenie.com, the matching key field appears and Root Lock posts that vendor’s native format instead of the generic payload.

Example generic payload (a Lockdown block):

{
  "node_id":            "prod-web-03",
  "event_type":         "new_program_blocked",
  "timestamp":          "2026-03-31T14:22:00Z",
  "mode":               "Secure Mode",
  "lockdown":           true,
  "tier":               2,
  "paths":              ["/tmp/dropper", "/tmp/payload"],
  "count":              2,
  "message":            "2 previously unseen programs blocked.",
  "subscription":       "Active",
  "total_pending":      2,
  "pending_programs":   2,
  "pending_file_r":     0,
  "pending_file_w":     0,
  "pending_network":    0,
  "enrich_failed":      false
}

mode is the on-disk token ("Setup Mode" or "Secure Mode"). The Dashboard label for "Secure Mode" is Lockdown. lockdown is the seal boolean. tier is 1 when you switch between Setup Mode and Lockdown, and for allowlist, backup-coverage, and kernel-module config changes. It is 2 for denied programs, files, and network.

Supported targets:

• PagerDuty Events API v2 (routing key field appears for pagerduty.com URLs)
• OpsGenie Incoming Webhook (API key field appears for opsgenie.com URLs)
• Slack Incoming Webhooks
• Generic HTTPS JSON receivers

Test Webhook ([w]) sends a test POST, so you can confirm the receiver accepts the payload before a real alert depends on it.

Status JSON (pull-based monitoring)

A passive, always-on snapshot is written every 60 seconds to ~/.cache/heartsuite/status.json. No Fleet setting turns this on or off.

Fields of particular interest for health checks:

• mode, is_hs_kernel, lockdown, daemon_ok, node_id
• pending_* counts (non-zero in Lockdown usually indicates something needs investigation)
• channel_errors (email, syslog, webhook), each with message and at

Tools that can consume it directly:

• Ansible facts / custom modules over SSH
• Nagios / Icinga / Zabbix (SSH or file checks)
• Any script that cats or jqs the file on a schedule

Policy and posture data in Elastic and Kibana

In addition to the enforcement and alert streams, Root Lock can emit structured policy and posture data — snapshots of the current allowlist and periodic reports of the host’s protection posture. When ingested into Elasticsearch, that data supports views of the allowlist across your fleet.

Use it for:

• Tables of approved programs with their exact file and network grants
• Counts of programs, broad-write risks while locked down, and reporting hosts
• Drift detection by comparing each host with the allowlist you keep in Git
• Filtering for higher-risk entries using risk_level, has_broad_write, has_network_grant, and lockdown_active_at_capture

Use the Dashboard on individual hosts to review the queues, change the allowlist, and activate Lockdown. Use the central view for scanning, filtering, and correlating posture at fleet scale.

Production path on real hosts

On production hosts, ship enforcement and alert streams via syslog or Filebeat as described above. Ingest into your existing Elasticsearch cluster and build Kibana dashboards with your standard security, retention, and access controls. Alert Settings has no policy-or-posture export switch — Fleet configures syslog and webhook only. No separate HeartSuite download is required for this path.

tools/kibana-bridge (optional evaluation stack)

For lab, evaluation, and customer demos, HeartSuite offers tools/kibana-bridge/: an optional disposable Docker stack (Elasticsearch, Kibana, and a small ingest receiver) that turns Root Lock telemetry (apo_change, heartbeats, enforcement) into policy-centric Kibana views.

heartsuite-install.sh does not install it. Request an evaluation kit from support@heartsecsuite.com or use the materials included with your coordinated release delivery.

The bridge is a read-only view that sits beside the syslog enforcement streams; production needs only those streams. Typical views include:

• A living allowlist table (one row per program_path with grant counts, risk_level, has_broad_write, has_network_grant, and related fields).
• KPI-style posture metrics (policy counts, broad-write risk while locked down, high-grant surface, recent blocks).
• Drift detection by comparing each host with the allowlist you keep in Git.
• Enforcement correlation for drill-down alongside policy rows.

The stack is localhost-only, security-disabled, and throwaway (docker compose down -v wipes volumes). Do not publish Kibana, Elasticsearch, or the ingest receiver on a public IP without a network perimeter — for example a cloud firewall allowlist of known lab addresses, or an SSH tunnel so the browser reaches only localhost.

Use the production path above for real access control, TLS, and retention.

Versus tools/siem-test/: These are sibling evaluation fixtures with different purposes (both available on request, not on production hosts):

They can run side by side on the same machine (different ports).

Quickstart (evaluation):

cd tools/kibana-bridge
docker compose up -d
docker compose run --rm setup
# Open http://localhost:5601 (or http://127.0.0.1:5601)

After setup, Kibana includes preconfigured data views:

• HeartSuite Policies — primary view for the living allowlist table (Lens tables); compare it with the allowlist you keep in Git to find drift.
• HeartSuite Events — raw telemetry and event drill-down in Discover.

An optional imported dashboard, HeartSuite - Policy Overview, may also be present when saved objects are bundled with your checkout.

To feed live data during lab work, forward syslog or the evaluation-kit telemetry to the bridge ingest receiver, or ingest exported policy data into your production Elasticsearch using the same field model. Setup detail is included in the evaluation kit README shipped with tools/kibana-bridge/.

Pairing with Ansible central policy

The exported policy data model pairs with Ansible (or Terraform/GitOps) central policy: curate one allowlist in your repo, push via the heartsecurity.root_lock Ansible role, /.hs/sys/batch_record_add.py, or /.hs/sys/hs-app-perm-orders-manager, and use Kibana tables and KPIs for fleet visibility. Compare the allowlist you keep in Git for drift. Git history is the policy change record. Policy identity is not on status.json, syslog, webhook, or Kibana.

The bridge (or your production Elasticsearch deployment) is the read side. Your control plane remains the write path.

See Central Policy Management and External Control for Ansible role variables, seed application, harvest patterns, and composition with full server deployment playbooks.

Verification commands (run on the HeartSuite host)

# Recent alerts and enforcement decisions (journal identifier is heartsuite)
journalctl -t heartsuite --since "10 minutes ago"

# Status snapshot (for pull monitors)
cat ~/.cache/heartsuite/status.json | jq .

Relationship to the Dashboard

All channels are configured from the Dashboard: Alerts ([e]) opens Alert Settings. The Fleet tab is the place for syslog, webhook, and Setup Mode Alerts. Status JSON is written whenever the alert daemon is running. Email remains available as a supplementary or low-volume channel.

At fleet scale: syslog for the SIEM, webhook for incident response platforms, and Status JSON for infrastructure-as-code health checks. The Dashboard remains the place for initial setup, exception review, and maintenance — not for ongoing fleet monitoring.

Policy management is the inbound complement: your central systems curate and apply allowlists via the shipped CLI tools, pre-seeding, and automation patterns. See Central Policy Management and External Control.

Once at least one push channel is configured, you can proceed to Lockdown.

For the UI configuration steps in detail, see the parent Alert Settings page.

2 - Drive the allowlist from your own tooling

Overview: Root Lock by HeartSuite is designed to be driven by your existing central tooling. The Dashboard is the surface for a single host. At fleet scale, your control planes curate policy, apply it to each host, and collect what each host reports back.

Cloud Path and Local Path remain how each host is installed. This page covers the fleet work around that install: harvesting an allowlist baseline from one host, installing that seeded package on many hosts, and applying extras without a Dashboard session on every machine.

Each host enforces its own allowlist, and Lockdown seals that allowlist on the host. HeartSuite has no central server that pushes policy to many hosts — your automation applies it per host, and each host exports status, alerts, and an approval log for central visibility and attribution.

Keep policy curation, change approval, and fleet-wide visibility inside the tools you already run (Ansible, Terraform, GitOps repositories, ServiceNow, Splunk, Elastic, custom orchestration).

Policy curation in your central systems

A repository you already run — usually Git, applied by Ansible, Terraform, or similar — holds the list of approved programs, file-access paths, and network destinations. Your CMDB keeps describing hosts and apps, and your ITSM tickets keep approving changes; the repository is where the grants themselves live.

• Keep policy as text lists (one absolute program path per line) or structured data your automation can parse.
• Put changes through your normal processes: code review in Git, change tickets in ServiceNow, or a policy-as-code pipeline.

Two ways to seed the allowlist

Root Lock accepts seed policy at two points. An install-time baseline gives a new host the full allowlist of a host that already ran the same workload, so initial setup finishes quickly instead of running a multi-hour observation period on every node. A post-install program list adds programs to a host that is already running Root Lock.

A program list carries program paths; the installer baseline also carries each program’s grants and is what shortens initial setup. Re-applying a harvested baseline as a text list after initial setup therefore gains nothing. Program lists earn their place for role-scoped bootstrap lists (for example SSH and application entry points), for stack extras you approve after reviewing the queues, and for hosts that never ran those paths during setup.

Seed a fleet from one reference host

1. Reference host. Run initial setup on one host of this class under its real, full workload, then review what remains in the queues. If this host was installed without a baseline, this is the one time the fleet pays the multi-hour observation period.
2. Harvest the installer baseline from that host with the harvest and packaging tooling. Ansible can orchestrate the collection over SSH. The result is installer baseline material — programs and their grants — for step 4, not an hs_seeds list.
3. Review the baseline and promote it into your package pipeline.
4. Build or obtain a Root Lock install package with baseline pre-seed enabled (for example installer option --apo-seed). Packages can ship with pre-seed off; enable it here.
5. Start each fleet node from a clean OS.
6. Install Root Lock with Ansible, pointing the playbook’s install bundle at the pre-seeded installer. Initial setup starts from the baseline and finishes quickly.
7. Deploy application and hardening automation, then review only the differences in the Dashboard.
8. Optional: harvest extras with get_allowlist_programs() from the limited_tools Python API, which prints one program path per line, and review the paths. Apply them with hs_seeds, which approves each program path, or with batch_record_add.py, which approves those paths and also grants read on /usr/lib and /etc.
9. Activate Lockdown once the subscription, alert, and queue checks pass.

The first reference host of a class has no baseline to start from: install it on a clean OS without pre-seed, let initial setup run under the real workload, review the queues, and harvest from step 2. Every later host follows the order above.

Seed only what the reference host’s real workload ran, and leave out paths from test runs or one-off commands. An item in the pending queue becomes a grant only when you approve it.

Applying policy from automation

Use the CLI tools shipped with every installation (documented in the Appendices and Batch Allowlisting Tools) to apply post-install policy from your control plane:

• /.hs/sys/hs-app-perm-orders-manager — inspect current state, add or remove specific entries for programs, file paths, and network destinations. /.hs/sys is not on PATH, so call it by its full path.
• batch_record_add.py — bulk-seed programs from a plain-text list of paths (adds each with standard library and configuration directories).

Run these tools over SSH, via config-management agents, or as part of provisioning scripts after Root Lock is installed and initial setup is complete. Your central system prepares the seed data or change set; the automation layer delivers and applies it to each target host.

Subscription activation (hs-activate-subscription) is still required on each host before Lockdown can be engaged — this is the entitlement step and remains local.

Examples for the primary integration patterns follow.

1. Ansible — playbooks for seeding and applying policy

HeartSuite provides an official declarative Ansible role (heartsecurity.root_lock) for fleet policy application and Lockdown transitions. It is modelled on linux-system-roles.selinux and ships with coordinated release materials; email support@heartsecsuite.com if you need the role package.

On every installed host, the limited_tools Python API under /opt/heartsuite is the runtime integration surface the role uses. A shell-and-CLI alternative using batch_record_add.py and hs-app-perm-orders-manager follows below for ad-hoc or legacy playbooks.

Official Ansible role: heartsecurity.root_lock

Overview: The role provides variable-driven management of allowlist programs and mode transitions. Re-running a play does not create duplicate entries. It is modelled on linux-system-roles.selinux (and rhel-system-roles.selinux) so administrators familiar with RHEL declarative SELinux policy can apply the same playbook patterns.

The role assumes Root Lock is already installed. It focuses on allowlist management plus mode transitions (Setup Mode / Lockdown). Full server provisioning — base OS preparation, hardening (for example the dev-sec collection), SFTP receiver setup, bundle-based installation, and post-install configuration — belongs in thin orchestrator playbooks that compose heartsecurity.root_lock with upstream collections and host-specific tasks.

A reference provisioning example for a Debian 12 server is in the code repository under ansible/examples/hs-debian12-provision/. The pattern: install Root Lock and let initial setup run, start with a minimal role-scoped bootstrap allowlist from a seed file, and run the real workload. After you review the queues, keep the extra programs Setup Mode logged in a seed file and re-apply it with the role on the hosts that need those paths.

Requirements:

• Root Lock already installed on managed hosts.
• Initial setup finished before you apply workload hs_seeds or stack playbooks that expect a reviewed baseline.
• become: true — all operations are privileged.
• Ansible >= 2.9.
• The role invokes the production Python API in /opt/heartsuite (limited_tools via /opt/heartsuite/venv/bin/python3 and /opt/heartsuite/src).

Key variables (all prefixed hs_ to avoid collision with SELinux role variables):

Additional variables include hs_gather_status (default true, exposes hs_status fact), hs_purge / hs_purge_allowlist (emit a warning only — the scriptable surface adds entries by design), and hs_python / hs_src_path overrides for non-standard install layouts.

Re-run behaviour: All allowlist operations return CommandResult with kind == "noop" when an entry is already present. The role uses this for correct changed_when reporting, so repeated plays do not show spurious changes.

Minimal example playbook:

# heartsuite-root-lock.yml
- name: Configure HeartSuite allowlist and engage Lockdown
  hosts: heartsuite_fleet
  become: true
  vars:
    hs_state: secure
    hs_programs:
      - /usr/sbin/sshd
      - /usr/bin/python3
    hs_seeds:
      - /var/lib/ansible/heartsuite/seed.txt
  roles:
    - heartsecurity.root_lock

After switching to secure or lockdown, a reboot is typically required for full seal; the role does not reboot automatically. Register facts (hs_status, hs_apply_result, hs_switch_result) are available for assertions or subsequent tasks.

Python API alternative: For custom Ansible modules or non-Ansible automation, the same functions are exposed via limited_tools: approve_program_path, apply_allowlist_seed, get_status, get_allowlist_programs, and switch_to_secure. These reuse the same gates and CommandResult semantics.

The heartsecurity.root_lock role is the preferred declarative path for post-install allowlist and mode work. Use the Python API (or thin custom tasks) when composing larger provisioning playbooks that also handle OS setup, hardening, or host-specific services.

See the reference provisioning starter in the code repository (ansible/examples/hs-debian12-provision/) for composition: it delegates SSH/SFTP hardening to the dev-sec collection, performs bundle-based installation, registers backup directories and alert configuration, starts with a minimal allowlist bootstrap, and shows how to harvest from real workload observation into a seed file before using the role for allowlist and mode.

Use these playbooks to carry out the change records your central system approves.

Shell + register alternative

Use Ansible to distribute seed files and invoke the batch or management tools with become: true:

# heartsuite-policy-apply.yml
- hosts: heartsuite_fleet
  become: true
  tasks:
    - name: Copy central program seed list
      copy:
        src: "policy/seeds/programs-{{ inventory_hostname }}.txt"
        dest: "/tmp/heartsuite-programs.txt"
        owner: root
        mode: '0600'

    - name: Apply baseline programs via batch tool
      shell: "/.hs/sys/batch_record_add.py /tmp/heartsuite-programs.txt"
      args:
        creates: "/.hs/sys/allowlist_applied_{{ inventory_hostname }}.stamp"

    - name: Apply targeted network and file deltas from central policy
      shell: |
        /.hs/sys/hs-app-perm-orders-manager add -x /usr/bin/curl -n 93.184.216.34
        /.hs/sys/hs-app-perm-orders-manager add -x /usr/bin/curl -d /etc/ssl/certs
      # Idempotency and error handling left to your playbook

    - name: Harvest the applied program list on the host
      shell: >
        /opt/heartsuite/venv/bin/python3 -c "import sys; sys.path.insert(0, '/opt/heartsuite/src');
        from core.limited_tools import get_allowlist_programs;
        print('\\n'.join(sorted(get_allowlist_programs() or [])))"
      register: hs_allowlist
      changed_when: false

    - name: Record application in central audit
      copy:
        content: "{{ hs_allowlist.stdout }}\n"
        dest: "policy/harvest/allowlist-{{ inventory_hostname }}.txt"
      delegate_to: localhost
      become: false
      # Then commit the harvest back to your policy repo

Without the role there is no CommandResult.kind == "noop" to drive changed_when, so add your own re-run checks (for example creates, or register + conditional tasks).

2. Splunk / Elastic (and similar SIEMs) — ingesting for central dashboards and policy triggers

The primary use of Splunk and Elastic is consumption of the structured data streams (see SIEM and Fleet Integration). Once events are in the SIEM:

• Build dashboards showing per-node mode, pending counts (from status.json), block rates, and approval activity (from the JSONL approval log forwarded via syslog or other shipper).
• Build views of the current allowlist and associated risks from the structured policy snapshots and posture data, including tables of programs with grant counts, risk_level, and broad-write and network flags. Compare the allowlist you keep in Git for drift. Policy identity is not on status.json, syslog, webhook, or Kibana.
• Use SOAR playbooks or alert actions in the SIEM to trigger Ansible Tower / AWX jobs or Terraform runs that apply approved policy updates back to affected hosts.
• Correlate HeartSuite enforcement events with change tickets to close the audit loop.

Syslog is the recommended high-volume path for both the per-decision enforcement stream and higher-level alerts. For richer views of the allowlist and posture (tables, metrics, and correlation) see SIEM and Fleet Integration.

3. Terraform + GitOps — policy in repository, applied at provision and drift remediation

Store allowlist seeds and change manifests in the same Git repository as your infrastructure code.

• Use Terraform local_file or templatefile to render per-host or per-role seed files from a central policy definition.
• During terraform apply, a remote-exec provisioner, local-exec that calls Ansible, or a custom provider runs the seed application and hs-app-perm-orders-manager invocations on the new or updated instance.
• Drift detection: scheduled jobs (or Terraform Cloud/Enterprise runs) harvest the program list with get_allowlist_programs() from the limited_tools Python API, compare it with the allowlist you keep in Git, and open PRs or apply corrections. status.json is the health snapshot, not the policy identity.
• Git history becomes the authoritative change record for policy; the on-host JSONL approval log provides the per-host attribution of when and by which uid/tty the change was executed.

This pattern works especially well for immutable or frequently reprovisioned fleets.

4. ServiceNow or ITSM platforms — change-driven policy

• Model allowlist additions, removals, or baseline updates as standard or emergency change requests.
• Approved changes update the Git (or equivalent) policy repository, then automation applies them per host.
• The automation (Ansible, scripts, or ServiceNow Flow Designer + MID server) applies the delta to the target hosts using the CLI tools above.
• On completion, the automation closes the change ticket and posts the resulting JSONL approval log excerpts (or a pointer to the SIEM record) as evidence.

This keeps policy changes inside the same approval workflow used for all other infrastructure changes.

5. Custom scripts and other configuration management (Puppet, Chef, Salt, etc.)

Any tool that can copy files and run commands as root on the target can drive policy:

• Puppet: a custom resource or exec that writes a seed list managed by Hiera or PuppetDB and then invokes batch_record_add.py or hs-app-perm-orders-manager.
• Chef: a recipe that templates policy from a data bag and executes the CLI tools.
• Pure scripts (Python, Bash, or your language of choice) run from a central runner or cron on a bastion: query the authoritative policy store, compute the diff for each host (or use a node-specific tag), SSH in, and apply.

The dedicated JSONL approval log (with uid/tty attribution for each change) and the enforcement/alert syslog streams give you the same audit trail regardless of which tool performed the apply.

Consuming data for central visibility, auditing, and harvesting

Status JSON and the JSONL approval log are written whenever the alert daemon is running. Syslog is off until you enable it on Alert Settings → Fleet. Webhook requires an HTTPS URL on that same tab.

• Status JSON (~/.cache/heartsuite/status.json, updated every 60 seconds) — lightweight pull surface for health and pending counts. Use from Ansible facts, Nagios/Zabbix checks over SSH, or any scheduled collector. Key fields for fleet dashboards: mode, lockdown, is_hs_kernel, daemon_ok, pending_* counts, node_id. See the schema in the Appendices.

• Dedicated JSONL approval log (/var/log/heartsuite/allowlist-audit.log) — persistent, append-only record of every allowlist approval (not skips or removals) with timestamp, uid, and tty. This is the primary artifact for change attribution. Forward that file with your existing log shipper. It is not copied into syslog.

• Structured syslog streams — when Fleet Syslog is on, denial lines (HS-PROG-DENY, HS-FILE-DENY, and similar) and aggregated alerts (new_program_blocked, mode changes) share ident heartsuite. Alert lines use the message prefix heartsuite-alert:. A single rsyslog rule forwards both. Full configuration examples and Filebeat patterns are in the SIEM and Fleet Integration page.

• Webhook — HTTPS POST of compact JSON alert payloads on every significant event. Configure the endpoint in Alert Settings; use for immediate routing into ServiceNow, PagerDuty, or your own policy-evaluation service.

• Harvest current allowlist state — run get_allowlist_programs() from the limited_tools Python API, or /.hs/sys/hs-app-perm-orders-manager view -a for each program’s grants, on a schedule or on demand and commit the output to your central policy repository. This closes the loop: central sees what is actually enforced on each host and can detect drift or feed the next baseline.

See Alert Settings for configuration of syslog and webhook (Fleet tab) and SIEM and Fleet Integration for production-scale ingestion patterns.

Relationship to the Dashboard and Lockdown

The Dashboard remains the right surface for one-off investigation, initial setup on a new host, and guided maintenance windows. At fleet scale, routine policy application and observation move to your central tooling.

While Lockdown is on, alerts for programs waiting in the pending queues go to every configured channel.

Central automation drives allowlist policy and first install. It does not lift Lockdown.

• Similar hosts, first install: harvest once, package with install-time pre-seed, Ansible installs that package — the order above.
• Already in Lockdown: the official role does not unseal. hs_state: setup leaves mode unchanged. Package installs and Root Lock bundle updates wait for Setup Mode — Protecting During Maintenance and Updating Root Lock.
• Many locked hosts: reprovision from an updated image rather than a console session per node — Enterprise Adoption Guide.

Next steps and related documentation

• Configure the base alert channels on a pilot host: Alert Settings
• Review the CLI tools available for automation: Batch Allowlisting Tools and Appendices.
• Set up log ingestion: SIEM and Fleet Integration.
• Understand maintenance windows, unseal, and fleet image reprovision: Maintenance.
• Compliance context for auditors: SOC 2 Control Mapping and Compliance Reference: NIST CSF & ISO 27001.

For support with large-scale or custom automation patterns, contact support@heartsecsuite.com.