Building NHI Detection Rules That Don't Generate Noise

Behavioral baselining for non-human identities and NHI detection rules starts with the signals you have. Most teams skip baselining because they think it requires a perfect identity inventory and months of clean telemetry. It doesn't.

It requires enough signal to separate operational patterns from abuse patterns. Start with the fields your environment already emits reliably: source host, destination service, auth mechanism, environment, token type, API operation, time of day, frequency, failure rate, and any privilege elevation event tied to the identity.

That is your starting dataset. If your logs do not include enough of that context, fix the logging pipeline before you write another detection rule.

For service accounts, the most useful baseline dimensions are usually where they authenticate from, what they authenticate to, and whether their call pattern is steady or bursty. A Windows service account that has historically authenticated from three hosts and touched one SQL backend should not suddenly begin authenticating from a jump box and talking to storage infrastructure.

An API key used exclusively from one workload subnet should not appear from a new egress point in a different environment. These are not exotic detections. They are basic consistency checks, and they catch real abuse when you tune them against known identity behavior instead of broad enterprise averages.

High-variance machine behavior is where weak detection programs go to die. Some NHIs are inherently noisy because the workload behind them scales, fails over, or fans out dynamically.

That does not mean you give up and label them “too noisy to monitor.” It means you baseline by identity class when per-identity baselines stop being stable enough to matter.

For example, short-lived deployment tokens used by the same CI platform can often be baselined as a class around approved destination sets, expected issuance paths, and allowed environment boundaries. Likewise, Kubernetes service account tokens can be modeled around namespace, cluster, node pool, and expected cloud API touchpoints. The baseline does not need to be perfect. It needs to be discriminating.

What to collect before you tune

For each NHI, collect at least: identity name or client ID, credential type, workload or host mapping, trust boundary, source network pattern, target resource set, authentication method, issuance path, privilege level, expected schedule or trigger pattern, and whether the identity should ever cross environments. If you cannot answer half of those, that gap is already part of the detection problem.

Be careful with time-based heuristics. “Off-hours activity” is useful for human identities because humans sleep. Machine identities do not.

Off-hours is only meaningful if the machine identity has a narrow schedule or maintenance window. A payroll integration that runs nightly at 2:00 AM should not alert every time it does exactly that.

A service principal that normally pulls secrets only during a deployment window should absolutely raise eyebrows when it starts authenticating at noon on a Sunday from a subnet it has never used. Time matters, but only in the context of the workload’s actual operating rhythm.

Write correlation rules for abuse patterns, not for isolated odd events

The fastest way to create garbage alerts is to fire on single weak signals. One failed login from a service account is usually nothing. One call to a new API method might be a software update.

One token refresh from a new pod could be routine rescheduling. Useful NHI detection rules combine signals. They look for sequences, contradictions, or changes in behavior that do not line up with the identity’s role.

A good example is token reuse across trust boundaries. If the same OAuth client token or API credential appears in both non-production and production telemetry inside a short interval, that is rarely normal. That rule works because it is tied to a control expectation: credentials should be environment-scoped.

Another solid pattern is lateral expansion after initial authentication. If a service account that normally talks to one message broker suddenly authenticates successfully and then starts reaching laterally into configuration stores, identity systems, or secret managers, you have a much stronger abuse signal than “new destination observed” alone. The logic matters because the sequence tells a story.

Example rule pattern:

IF identity_type = "service_account"

AND auth_success = true

AND new_source_host = true

AND target_resource IN high_value_resource_group

AND baseline_confidence > 0.7

AND recent_change_window DOES NOT include approved deployment

THEN raise high-severity alert

ELSE enrich only

That last line matters. Not every anomaly deserves an alert. Many deserve enrichment first. A lot of vendor rules fail because they turn every baseline deviation into a case.

In practice, some deviations should just add context to the next event. If a build runner starts using a new subnet because the platform team added nodes, the signal still has value. It just should not page someone by itself. Mark it, track it, and let it strengthen a later detection if the same identity also accesses a new secret path or starts calling administrative APIs it has never used before.

Some anomaly types are consistently worth serious attention. Authentication from a new source combined with privilege-bearing API calls. Repeated access denials followed by a successful call to an adjacent resource. Use of long-dormant credentials.

Machine identities initiating administrative actions outside their historical lane. Token or key reuse across environments. Service accounts suddenly pivoting into IAM, KMS, secrets, or metadata services they do not normally touch. Those are the kinds of behaviors that often accompany compromise, misconfiguration, or uncontrolled credential reuse.

Some anomaly types are usually not worth a standalone alert. A service account hitting a known endpoint at a slightly different rate during a release. One-time failed auths during node replacement. Short-term spikes from autoscaling.

New pod IPs inside an expected cluster range. Those should usually be suppressed, thresholded, or enriched unless they stack with something riskier.

Good SIEM engineering is not just about detection logic. It's about restraint.

Rule-writing principle

If you cannot explain why a rule should fire in one sentence that includes the identity’s normal job, the rule is probably too generic. “Detects suspicious service account activity” is useless. “Detects deployment identities authenticating from non-runner hosts and touching production secrets outside approved release windows” is a rule you can defend.

Tuning against your actual environment is where the real engineering happens

Vendor defaults fail because they were not built for your identity topology, your asset tagging discipline, your workload lifecycle, or your operational sloppiness. They don't know which subnets are shared by legacy middleware. They don't know that half your service accounts are still used by scheduled tasks on servers nobody wants to reboot. 

They do not know that your staging environment leaks traffic patterns into production telemetry because someone copied an API client and never rotated the credentials.

They are not maliciously bad. They are just generic. Generic is not the same as useful.

The first feedback loop is simple: review every alert with the question, “What context would have prevented this from paging us?” Sometimes the answer is a tag. Sometimes it is an approved change calendar. Sometimes it is a missing host-to-workload map.

Sometimes the answer is that the rule should never have been promoted out of testing. Tuning is not only about thresholds. It is about admitting what the rule did not know when it fired and deciding whether that missing context is maintainable.

Asset context is one of the biggest force multipliers you have. If your detections can consume environment tags, application ownership, credential type, privilege tier, deployment windows, and resource criticality, the rule quality improves immediately.

A new source IP for a service account on a low-tier integration worker is not the same as a new source IP for a privileged automation identity that can touch your cloud control plane. Same signal, different risk. If your SIEM treats them equally, your analysts will stop trusting it.

This is also where you need discipline about deprecating rules. Some rules are just bad fits for the environment. If a correlation rule requires five suppression layers and still floods the queue every Monday morning, kill it or rebuild it.

There is no prize for keeping a noisy rule alive because it looked good in the design doc. Analysts remember which alerts waste their time. Once they mentally classify a use case as noise, it becomes much harder to recover trust later.

A practical tuning loop looks like this: deploy the rule in monitor mode, collect two to four weeks of hits, sort by identity class, identify the top false-positive drivers, add missing context or scope boundaries, test again, and only then move to paging. After promotion, keep a weekly review for the first month and a monthly review after that.

Measure not just hit volume, but investigation outcome quality: true positives, benign-but-interesting, known change, poor telemetry, or useless. If you are not classifying outcomes, you are not tuning. You are just accumulating annoyance.

Useful tuning dimensions:

- identity class (service account, OAuth client, API key, workload token)

- environment (prod, non-prod, shared services)

- source trust zone

- target sensitivity tier

- approved change window overlap

- credential age and rotation history

- dormant vs. active identity status

- owner/team metadata availability

The hardest environments are the ones with weak ownership data and messy legacy patterns. That is exactly why your detections need to help surface the mess instead of pretending it does not exist. If a machine identity has no owner, no clear source host, and no stable usage pattern, the answer is not to exclude it from monitoring because it is inconvenient.

The answer is to raise the priority of inventory, ownership mapping, and credential hygiene around that identity. Detection engineering cannot compensate forever for broken identity governance. It can, however, show you where governance debt is creating blind spots.

The goal is not more alerts; it's earlier, clearer signal

A good NHI detection program does not try to detect every strange event. It tries to make high-confidence abuse visible before the blast radius gets large. That means fewer, stronger rules built on real workload behavior. It means better enrichment.

It means suppressing expected operational churn instead of pretending every deviation is a threat. It also means accepting that some environments are not mature enough yet for certain detections to work cleanly. Say that out loud. Build the prerequisites. Then write the rule.

If your current NHI detections are all noise, the fix is probably not a cleverer query. It's usually better identity context, tighter baselines, and the willingness to delete rules that never should have made it to production.

That's how you get from dashboards full of machine-generated nonsense to detections your analysts will trust when something real goes sideways.

Take the next step today

Time to create or maintain your non-human identity program? Talk with our team now for customized insights on your best next steps.