Cold Start: Entities With No History

Behavioural analytics needs a past. New entities have none, and the answer is not to wait — new joiners, new contractors and newly provisioned service accounts are a meaningful risk population precisely during the window when they cannot be modelled.

Where cold start occurs

New employees and contractors. No individual baseline for weeks.

New service accounts. Frequently provisioned with broad privilege and no established pattern.

New hosts. Reimaged, replaced or newly deployed.

Role changes. The existing baseline is not absent but actively misleading, which is worse than nothing.

Return from long absence. Parental leave, sabbatical, long illness. The baseline may be stale and the gap itself confuses some implementations.

New deployments. Every entity is cold simultaneously, which is why the first weeks of any UEBA rollout produce unusable volume.

What to use instead of an individual baseline

Peer group comparison. The primary answer. A new starter has no history and does have colleagues. Comparing against the group is the only detection available in week one, and it works reasonably where groups are well constructed.

This is the strongest argument for investing in peer grouping before deployment rather than after.

Role-based expectations. Derived from entitlement rather than behaviour: what this role is authorised to reach. Access outside it is meaningful on day one, with no history required.

Absolute thresholds. Crude and available immediately. Volume beyond any plausible legitimate level does not need a baseline.

Rules. Known-bad patterns work without history. During cold start they carry the load.

Progressive confidence

The useful design treats baseline maturity as a first-class property rather than a binary.

Days 0–7: peer comparison and rules only. Individual deviation scores suppressed entirely — they are noise.

Days 8–30: individual baseline forming. Scores computed but heavily discounted, and surfaced only when peer comparison agrees.

Days 31–90: individual baseline usable for stable features first. Volume and diversity stabilise faster than temporal and sequential features.

After 90 days: full weighting.

Expose maturity to the analyst. "Baseline: 12 days, low confidence" prevents the analyst from treating an immature score as equivalent to a mature one. Very few products display this and it changes triage quality substantially.

Role changes specifically

The most damaging case, because the system does not know anything happened.

An employee moves from support to engineering. Their old baseline says they touch ticketing systems and never repositories. Their new job is repositories. Every day now produces deviation, and the analyst sees a person whose behaviour changed completely — which is exactly what a compromised account looks like.

The fix is an HR-driven trigger. A role change event should reset the individual baseline and move the entity to the new peer group. Without that feed, role changes generate weeks of noise and train analysts to dismiss the entity.

Where an HR feed is unavailable, entitlement changes are a usable proxy: a substantial change in group membership almost always accompanies a role change.

The deployment cold start

Every entity is cold at once. This produces the characteristic first-month experience — thousands of first-observed events, everything anomalous — and it is regularly mistaken for a tuning failure.

Run silent for the full baseline window. No alerts, no user-visible effect. This is not caution; the output is genuinely uninformative.

Establish peer groups before entity baselines so that something is available earlier.

Expect the score distribution to shift for months as baselines mature. Thresholds set in week two are wrong by week ten.

Instrumenting baseline maturity

The mechanism that makes cold start manageable, and it is straightforward to build.

Store, per entity and per feature, how many observations the baseline contains and over what span.

Derive a confidence level — none, low, medium, full — from those counts, with thresholds set per feature since some stabilise faster than others.

Gate alerting on confidence. Suppress individual deviation alerts below medium; require peer agreement at medium; alert normally at full.

Display it to the analyst on every alert. "Baseline: 14 days, low confidence" changes how the alert is read, and it takes one line of interface.

Report the distribution. What fraction of entities have full-confidence baselines is a genuine health metric for the deployment, and a falling fraction indicates churn or resolution problems.

Common false positives

Cold start produces a characteristic and heavy noise profile:

New joiners flagged for everything in their first fortnight, because everything is first-observed.

Role changes producing sustained deviation against a baseline for the previous job.

Return from leave, where the gap and the catch-up both look anomalous.

Newly provisioned service accounts performing their intended function for the first time.

Reimaged hosts with no history under their new assignment.

Deployment-wide cold start, where every entity is immature simultaneously and the entire first month is unusable as detection.

Each of these is predictable, which means each can be suppressed by rule rather than triaged individually.

Blind spots and assumptions

That absence of history means absence of risk. New contractors and new service accounts are a higher-risk population than the established workforce, and they are the least modellable.

That peer groups are available at day one. They depend on HR attributes, which are frequently not populated until after a joiner starts.

That maturity is visible. Most products score confidently regardless of how little history exists.

That the baseline stabilises uniformly. Different features mature at different rates, and treating them equally overweights the ones still forming.