Eiciel's software hardening is strong against someone working their way up from a foothold. On company infrastructure, the thing that actually decides your risk is who holds console, hypervisor, and cloud-IAM access — not just who has the SSH key.
Everything below is set once, at build time, in config/config.local.env, and baked into the ISO — there's no runtime toggle to accidentally leave at an insecure default.
Leaving ADMIN_CIDRS empty without setting ALLOW_OPEN_SSH=1 fails the build outright — this isn't a warning you can click past.
Over the network, Eiciel holds up: the SSH key gets a constrained shell, and root needs a separate TOTP code with no bypass we could find on a cold session. But console access — a datacenter KVM, a cloud provider's serial console, a hypervisor's VM console — skips both factors entirely. Whoever can reboot the box and reach its boot menu gets a root shell, by design, as the documented disaster-recovery path.
In a company deployment, that access isn't rare. It's held by your ops team, your cloud IAM roles, and your hypervisor admins as a normal part of the job — which means the real security question shifts from "is SSH hardened enough" to "who, in this organization, can reach a console for this machine, and is that list as short as it should be."
password_pbkdf2) before shipping to production — the boot menu has none by default.sudo's default 15-minute credential cache is acceptable for your threat model, or whether to force timestamp_timeout=0 so every privileged action re-checks TOTP.If the goal is tamper-evident incident response, you generally don't want the people who can reboot the box to also be able to silently reach root with no audit trail. That's a policy decision outside the software — Eiciel logs what it sees, but it can't log what happens before it's running.