Hardening (POSTAVA)

Deploy once. Monitor continuously. Every drift event is a substrate signal.

Most hardening tools are one-shot scripts. Run them, get a hardened host, and hope nothing changes. There is no mechanism to detect whether a future configuration change undermines the work. The hardened state is only true at deploy time.

SPNT's hardening module (POSTAVA) does two things differently.

First, the deploy is auditable and supply-chain-verified. The hardening binary carries a cryptographic manifest. Every module verifies state before and after application. The result is persisted as a set of control records.

Second, a drift agent runs continuously after deploy. When any monitored parameter deviates from the hardened baseline, the agent writes a control-health event to the substrate — which immediately triggers re-prioritisation of related findings, re-evaluation of affected compliance obligations, and inclusion in the next autonomous research pass.

One configuration change. Immediate awareness across the whole platform.

What POSTAVA hardens

The deploy operation

The hardening binary verifies its own cryptographic integrity before it does anything. A binary that has been tampered with between download and execution will fail its integrity check and refuse to run. The customer can independently verify the manifest using the published public key.

On execution, the binary reads the org-specific hardening specification, applies each module in order, verifies the post-apply state of each module against the specification, and writes the resulting control records to the substrate. If any module's post-apply verification fails, the deploy reports the failure and the partial state — it does not silently succeed.

The drift loop

After deploy, the drift agent monitors every hardened parameter continuously. Any deviation — a firewall rule removed, an SSH option changed, a kernel parameter modified — produces a control-health event in the substrate.

What happens next is the substrate-first model in practice:

• The control entity for the affected module updates its health status.
• Priority scores recalculate for any finding whose mitigation depended on that control.
• The governance module re-evaluates compliance obligations linked to the affected control category.
• The decision intelligence layer includes the drift event in the next research pass.

For Enterprise customers, the autonomous research engine treats clusters of control-health failures as a trigger condition — investigating automatically whether the pattern indicates a coordinated configuration change.

Customisation and intentional changes

The hardening specification is configurable per org and per asset. Customers can extend the default, restrict it to specific modules, or override individual parameters.

Intentional configuration changes can be acknowledged through the SPNT interface. An acknowledged drift event updates the baseline — the new configuration becomes the monitored state going forward. The original hardened baseline and the acknowledgement record are both retained for audit history.

Tier availability