Accounts, operators, and living systems

An account is a structured technical object with a person attached to it, or sometimes not, which fundamentally alters how it behaves. Attached accounts combine formal configuration with the specific habits, working hours, and operational authority of the people who use them.

Account attributes and service account dynamics

An account usually consists of a name, a set of memberships, an execution history, and an owner. Group memberships name the actions and resources the account is authorised for, while execution history shows a baseline of typical usage patterns regarding logon times, source locations, and active hours. This history can also inform on whether using an account unexpectedly will draw attention. The owner decides how a failure unfolds: a human user who is locked out often notices within a minute and calls IT, whereas a locked-out service account might quietly fail during a two in the morning batch job, generating a ticket that no one opens until Monday.

Service accounts are often worth analysing separately. Over time, non-human accounts tend to accumulate stale passwords, legacy group memberships, and unintended interactive logon rights.

Against that, service accounts usually operate within predictable, automated boundaries, so they can be exactly the accounts a rule watches, since a service account doing something new is one of the few reliable signals available to a defender.

Operational schedules and maintenance windows

Human operators run on schedules, and a schedule is as much a property of an estate as a firewall rule. Knowing who is on shift at three in the morning, who can approve a change without asking, or whether a maintenance window falls on the first or third Sunday is often what decides the shape of a plan. On an industrial process network, these operational schedules can show more than a network diagram does. A maintenance window may be the only period during which a controller can be rewritten without raising immediate alarm.

Third-party access and supply chain vectors

External organisations frequently retain quiet pathways into an internal network. An integrator that built a plant might still hold remote access set up for support years ago and never revoked, sitting completely outside an organisation’s current identity rules. Suppliers may maintain a tunnel for a single application alongside a firewall rule that is far broader than necessary, while managed service providers often hold administrative rights in the identity provider by design. Similarly, a helpdesk can be an identity-changing service with a human interface, which is why it is asked so often to reset things, and why its identity verification checks are critical to understand.

Each of those is a route belonging to somebody whose posture is not the one being assessed, and whose staff have never met most of the people they help.

Human telemetry and anomaly detection

The human operators who use these systems are also the ones most likely to notice when something goes wrong. A plant operator noticing an unexpected mode change on a control panel, a user getting locked out twice in a single morning, or a support agent sensing that a caller sounds rehearsed can all act as early detection systems. The softest edges of an organisation’s security boundary and its fastest operational alarms are often the exact same people.