Per collector, per site, or per fleet - how fine should a several-hundred-host fleet's credential identity be cut?

## The unit of action, not the unit of hardware The instinct is that finer is always better, so the ideal is one identity per host, per process, per run. The useful test is different: **what is the smallest unit you would actually take action on?** Scoping finer than your unit of action buys a distinction you will never exercise, and you pay its operational cost every day regardless. Two actions define the unit: - **Withdrawal.** Would you really stop one collector while its nineteen neighbours keep uploading? If the site's data is useless with one host missing, the honest unit is the site. - **Investigation.** When the record names a holder, what is your next move? If it is *quarantine the whole site and rebuild it*, then site resolution was all you needed. ## The arithmetic, stated with its assumptions Assume 400 collectors spread over 20 sites, so about 20 per site. | cut | holders per credential | identities to operate | radius of one leak | record resolves to | |---|---|---|---|---| | per fleet | 400 | 1 | the whole estate's uploads | the value only | | per site | 20 | 20 | one site | the site | | per collector | 1 | 400 | one host | the host | The middle row is the one teams under-use. It is a **twentyfold reduction in radius for five percent of the identity count** of the finest cut, and it converts an un-shrinkable suspect set into a group of twenty. If a fleet cannot get to per-host today, per-site is not a consolation prize - it is most of the benefit at a small fraction of the price. ## What the destination has to support Fine cutting is only available if the receiving system can hold many identities and withdraw them independently. Some destinations accept exactly one login for a partner and nothing finer; there, the holder axis is simply not offered, and the cuts you can still make are by right and by environment. Say this out loud when you answer - a plan that assumes an identity per host against a destination that has one account is not a plan. ## The costs that scale with identity count 1. **Enrolment.** Every new host needs an identity before it can upload, which means the identity must be created as part of building the host rather than by a human afterwards. 2. **Withdrawal on retirement.** Every retired host leaves an identity behind. One nobody removed is a holder you no longer track - a hole on the very axis you paid to close. 3. **Grants.** Hundreds of identities need their rights kept equal and kept narrow; divergence between them is invisible until an incident finds the one that was different. 4. **Diagnosis.** *This host cannot upload* becomes a per-identity question rather than a fleet-wide one, which is better for blast radius and worse for the support load. The first two are the ones that decide whether the cut survives. A per-host identity model that depends on a person remembering to create and remove identities degrades toward sharing within a year, because the pressure to reuse an existing value when a host is rebuilt at three in the morning is enormous. ## How to choose, in one paragraph Start from the incident you expect. If a single collector can be compromised independently and is worth investigating on its own, cut per host and make enrolment and withdrawal part of building and destroying the machine, not a human step. If collectors are identical, disposable and always handled as a group, cut per site or per role and spend the saved effort on the right axis instead, where the cut is cheaper and the reduction is often larger. Whichever you choose, say what you left standing: the group that still shares one value is the group you will not be able to tell apart when it matters.