--- title: "Hardening is a service, not a checkbox" url: "https://kybertis.com/blog/hardening-is-a-service" description: "A server hardened once and then left alone drifts back to soft. Why hardening is a state you keep rather than reach, and what changes once agents run on it." --- # Hardening is a service, not a checkbox October 8, 2026·4 min read·Editorial team Close-up of a server appliance corner with a precision torque driver set into one of its screws Picture an accounting office with twelve people and its own server in a cupboard. Three years ago an IT contractor hardened it against a checklist: strong passwords, a firewall, disk encryption, automatic screen locks. Every box was ticked, and the checklist is still in a folder, still all green. Since then a temporary admin account was created for a contractor who helped during the busy season, and nobody removed it. A firewall rule was opened so a scanner vendor could connect remotely, once. Updates have been postponed since the one that broke printing. Backups go to a USB disk every night, and nobody has ever tried to restore one. Last month someone set up an assistant to sort incoming client documents and, to get it working quickly, gave it the office manager’s login. The checklist says the server is hardened. The server says otherwise. The office is hypothetical, but none of the details are unusual. ## The real cause: hardening treated as a state you reach Hardening is usually bought as a project: someone comes, applies a list and leaves. But a system is not hardened the way a door is painted. It is hardened the way a garden is weeded. Every exception, every postponed update and every new program moves it away from the state on the checklist, and nothing moves it back unless someone is responsible for doing so. Agents make this more urgent, not less. A program that reads every client file and can send email is exactly what an attacker would want to borrow, and here it is running with a person’s keys. ## How hardening decays **Drift.** Each change made by hand on a running server makes it a little less like the system anyone documented. After a year, nobody can say what is actually on it. **Exceptions that never expire.** The rule opened for a vendor, the account created for a contractor. Each was reasonable on the day. None had an end date. **Updates postponed.** One bad update teaches everyone to wait, and waiting becomes the policy. The server falls further behind with every month in which nothing breaks. **Backups never restored.** A backup that has never been restored is a hope. The first restore attempt usually happens on the worst day of the year. **Agents with a person’s keys.** An agent given someone’s login can do everything that person can, at machine speed, and anything a convincing email asks it to. **A checklist with no threat model.** The list was written for servers in general, not for an office holding hundreds of clients’ tax records. It protects against the wrong things in the right order. ## Hardening as an ongoing service What we intend to sell is not the first pass. It is keeping the system in a known state for as long as you run it. **Start from the threat model you actually have.** Who would want what from this company, and how they would most plausibly try. One page, written down, so the measures that follow can be argued with. **A system that starts in a known state.** KyberLinux is designed to boot with a read-only root, verified from firmware up, with every service under least privilege, and to update by swapping whole images that apply completely or not at all. That turns drift from a matter of diligence into something the system is built to refuse. [One system from the wrist to the rack](https://kyberlinux.com/blog/one-system-from-wrist-to-rack) explains why the same base runs everywhere. **Your keys, enrolled.** The machine should answer to keys the company holds, not to the supplier’s. If we leave, the server still trusts you and stops trusting us. **Exceptions with an owner and an end date.** Every opened network rule, every extra account and every raised permission has a name next to it and a date it expires. When the date comes, it is renewed on purpose or it disappears. **Updates rehearsed, not postponed.** A new image is tested against a copy of your configuration before it reaches your server, and rollback is tried rather than assumed. Waiting stops being the safe option because it is no longer the only one. **Restore drills on a schedule.** A backup counts once it has been restored onto a clean machine by someone who did not make it. **Agents in cells, not in accounts.** Every agent runs in its own KyberCell: files and processes fixed when the cell is created, the network closed unless a rule opens it, secrets injected only where an authorised call leaves the cell. [How KyberLinux keeps a swarm in its cells](https://kyberlinux.com/blog/how-kyberlinux-keeps-a-swarm-in-cells) and [KyberCell explained](https://kyberagent.com/blog/kybercell-explained) go into the mechanism. **Evidence an auditor can read.** What was checked, when, by whom and with what result, kept as a record rather than reconstructed in the week before an audit. This is ongoing work, which is why it belongs in a support contract with [an SLA you can actually read](https://kybertis.com/blog/what-an-sla-on-open-source-means), not in a one-off invoice. None of it is on offer yet; [the KYBERTIS homepage](https://kybertis.com/) keeps the honest state of the work. ## A test you can run today Take the most important server or cloud account your business has, and make three lists: 1. Every account that can log in to it, people and programs alike. 2. Every network rule or remote access opened in the last year. 3. The date of the last backup that was actually restored, onto a different machine. Next to each line on the first two lists, write who asked for it and whether it is still needed. Every line without a name is drift. If the third list is empty, you do not know whether you have backups. - hardening - KyberLinux - KyberCell - security - operations ## Keep reading - [Rolling out KyberDeck to a team: devices, identities, spares](https://kybertis.com/blog/rolling-out-kyberdeck-to-a-team) - [What a Kyber deployment looks like, step by step](https://kybertis.com/blog/what-a-kyber-deployment-looks-like)