Most backup estates are joined to Active Directory because that is the fastest way to get them working. The backup server, the hypervisor hosts, the repository and the management console all authenticate against the same directory that every workstation uses. That arrangement is convenient on a Tuesday and expensive during an incident, since an attacker holding domain credentials already holds working access to the machines that hold the last good copy.
The usual response is to harden the domain itself. Tier the administrative accounts, shorten privileged sessions, alert on unexpected group membership. All of that is worth doing, and none of it removes the trust relationship. A machine joined to a domain accepts authentication decisions made somewhere else. If the place those decisions are made is compromised, the machine has no independent opinion about who is allowed in.
The useful question is narrower than whether backup should be isolated. It is which components can leave the domain without making the environment unworkable for a team of three or four, and what they then cost every week.
Domain membership does three things at once. It provides single sign-on for interactive logins. It provides a central place to manage local administrator group membership, security policy and software deployment. And it provides the Kerberos and NTLM plumbing that lets services authenticate without static secrets. The first is convenience, the second is management, and the third decides how an incident unfolds.
When an attacker reaches domain administrator, or any account that can edit Group Policy applied to the backup servers, no exploit against the backup software is required. They can add an account to the local administrators group, push a scheduled task or stop a service. Each is a supported operation performed with valid credentials, and tooling watching for malicious binaries will not flag it.
This is why published ransomware timelines so often show backup infrastructure being touched days before anything is encrypted. The access was already in place and only needed to be used. Separating the backup administrator identity from everyday administrative work is a genuine improvement, and it still assumes the machines honor a directory the attacker may already control.
The storage target is the easiest and returns the most. Object storage reached over S3 authenticates with access keys the platform itself issues, so it has no reason to consult a directory at all. A hardened Linux repository is close behind. Both are administered by very few people, and both hold the copy that has to survive everything upstream.
The backup server is harder and usually still possible. It needs to reach the hypervisor and the systems it protects, but that is an outbound authentication problem, not a reason for the server itself to join the production domain. Running it as a workgroup machine with named local accounts, or in a small management domain with no trust to production, keeps its login path independent.
Hypervisor hosts and the protected workloads normally stay joined, and that is acceptable. The aim is not an isolated production estate, which is unachievable in a mid-market environment. The aim is that the path from a compromised workstation to the deletion of a backup requires at least one credential the domain cannot issue. Management access is where this quietly fails, since a console reachable only through a domain joined jump host is isolated in name only, which is why the access path deserves the same attention as the segmentation of the storage network.
| Component | What isolation buys | What it costs to run |
|---|---|---|
| Object storage target | Deletion requires keys the platform issued, not domain credentials | Key issuance and rotation become a local written procedure |
| Hardened Linux repository | No policy path from the directory onto the machine | Patching and log shipping need a channel outside production |
| Backup server in a workgroup | Console logins survive an untrusted directory | Named local accounts, created and revoked by hand |
| Administrative access path | A compromised workstation holds no valid ticket to it | A separate route and a second credential for routine work |
| Monitoring and alerting | Alerts still arrive when the directory is in hostile hands | Local agent credentials and delivery tests on a schedule |
The losses are real and mostly boring. Single sign-on goes away for a handful of machines. Group Policy no longer enforces the security baseline, so the baseline becomes something applied at build time and verified by inspection. Certificates, time and name resolution all need a source that will not disappear with the domain.
The subtler loss is visibility. Domain joined machines are inventoried, scanned and reported on automatically. Isolated machines drop off those lists and can sit unpatched for months. Isolation and monitoring have to be decided together or the result is worse than what it replaced.
The first cost is account hygiene done by hand. Each administrator needs a named local account on each isolated machine, created deliberately and removed the day that person changes role. Shared local accounts defeat the purpose, since an audit trail that only ever shows the word administrator cannot answer who did something. Four people and three machines means a dozen accounts, small enough to write down and large enough to drift.
The second is credential storage. Local passwords have to live somewhere that survives the incident which made isolation worthwhile, so a password manager authenticating against the same directory is the wrong place. A separate vault with its own authentication, or sealed printed copies in a safe with a signed log of who opened them, are both defensible. Retrieving them must not require a working production environment.
The third is patching and everything else that quietly depended on the directory. Updates usually arrive from a management server inside production, so an isolated machine needs its own path and a named owner, because manual patching is the first commitment to slip. Certificate issuance, time, name resolution, log forwarding and directory integrated multifactor prompts each need a decision. Log forwarding should never be the one dropped, since a machine nobody watches is a different risk rather than a smaller one.
ARTESCA is object storage software used as a backup target on infrastructure the customer runs. Data access is through the S3 API using access keys the platform issues, so a backup job authenticates with a credential unrelated to Active Directory. That is structural rather than a hardening step, since there is no domain join to remove and no directory lookup in the data path.
Immutability is provided through S3 Object Lock, so an object under retention cannot be deleted before its retention expires even by a request carrying valid keys. Combined with credentials the domain cannot issue, that leaves two separate barriers between a compromised workstation and the backup copy, which is the reasoning behind a hardened repository or an object locked bucket rather than an ordinary share.
Because it runs on infrastructure the customer owns, the network boundary around it, the management of its keys and the list of people with operational access are all customer decisions. Isolation remains a deployment choice.
Write down which machines are domain joined and which are not, with a date and a one line reason beside each. That list is what everything else depends on, because an isolation decision living only in one person's memory is reversed by the next installer that asks for a domain account.
Once a quarter, attempt to log in to each isolated machine with a domain account and confirm it fails. That catches the most common regression, a machine rejoined during a rebuild or a vendor upgrade. At the same time, check the local accounts against the people who should still have them.
Twice a year, retrieve the local credentials by following the written procedure, performed by someone other than its author. Pair that with assuming the backup server itself is compromised and asking what still lets the team reach the storage and read data back. Before any hardware refresh or software upgrade, check whether the change reintroduces a domain dependency, since vendor installers frequently assume domain membership.