For most of the security industry’s history, logs were the problem to solve. Attacks were easy to spot in events: Failed logins, suspicious processes, and unexpected network connections. Infrastructure was relatively static, identities were long-lived, and configuration changed slowly enough to be treated as background context. SIEMs emerged to centralize logs, correlate activity across systems, and reconstruct what happened after the fact. Within that world, runtime data was the most reliable signal security teams had.

As SIEMs matured, they began to pull in elements of configuration to make the event data more meaningful. User roles, group membership, asset criticality, network zones, and CMDB data were used to contextualize alerts. But this configuration was never thoroughly implemented; it was modeled as tags and lookups, manually maintained, and assumed to be mostly stable. That assumption held for a time, until cloud and SaaS fundamentally changed what “configuration” meant.

In enterprises today, configuration is not a static context. Permissions are ephemeral, policies are layered and conditional, trust relationships span accounts and applications, and access is mediated through APIs and OAuth. SIEMs, optimized for events, were not built to continuously reason about or model this complexity. In the last decade, CSPMs and more recently SSPMs have emerged to fill that gap, treating configuration as a first-class concern. The result is that SecOps teams use one set of tools that tells what is happening, and another that tells what could happen, while real risk lives in the space between the two.

Prioritization Lives at the Intersection of Posture and Behavior

Security teams suffer from too many alerts, and most of them look equally important. CSPM and SSPM tools often surface thousands of risks, such as overly broad permissions, risky policies, misconfigurations, and exceptions. Meanwhile, SIEMs are often difficult to tune, resulting in highly noisy signals. This is where combining configuration with runtime behavior becomes essential.

Runtime behavior helps elevate dormant configuration risks when sensitive permissions are actively used in unexpected ways. Conversely, configuration context can help prioritize runtime anomalies that appear risky in isolation but have an outsized impact.

Permission analysis, for example, is far more actionable when it focuses not just on who is an admin or who is excessively privileged, but on which privileges are actually being exercised. A user accessing an application for the first time may warrant scrutiny, but that activity carries far less urgency when the user has only narrow, read-only permissions and no ability to modify data, change configuration, or escalate access.

Similarly, policy assessments become more meaningful when teams can see whether gaps, conflicts, or exceptions are merely theoretical or are being actively exploited through real activity. For example, an OAuth application with broad scopes or a storage resource with permissive access may represent latent risk for long periods of time. When runtime data shows that those permissions are actively used to access sensitive data, invoke privileged APIs, or operate outside expected workflows, the same policy finding moves from low-priority posture issue to high-priority security concern.

Instead of treating all risks equally, security teams can focus their attention where configuration and behavior intersect, where potential impact is most likely to become real.

Detection Requires Context

High-quality detections depend on reliable signals; however, API calls, file access, or authentication events are necessary, but rarely sufficient on their own. Configuration data provides the missing context that allows detections to distinguish between routine behavior and meaningful risk, particularly in dynamic cloud and SaaS environments.

One important class of detections centers on sensitive data access. In large organizations, it is common to have thousands of publicly accessible files, shared drives, or cloud storage buckets. Configuration data can identify which documents, buckets, or repositories contain sensitive or regulated data, while runtime events show which of those resources are actually accessed, materially improving detection quality.

A configuration context can enable more robust peer group and behavioral analysis. Users can be grouped based on organizational unit, cloud account, assigned roles, or effective permissions. These cohorts establish an expectation of normal behavior that runtime activity can be evaluated against. Deviations within a peer group, such as a user invoking APIs or accessing systems uncommon for others with the same permissions, can indicate misuse or compromise. Conversely, similarity across very different cohorts can be equally telling. For example, a user in a finance organization whose activity begins to resemble that of an IT administrator, such as interacting with identity systems, modifying access policies, or accessing infrastructure-level APIs, represents a behavioral anomaly that is difficult to detect using runtime data alone.

Identity lifecycle state can also provide critical detection context. Configuration data indicating whether a user is a contractor, scheduled for offboarding, or recently deactivated changes the meaning of otherwise routine activity. A bulk download, token use, or administrative action may be benign for a long-tenured employee, but highly suspicious when it occurs during a termination window or after deactivation. Correlating lifecycle signals with runtime behavior allows detections to surface patterns associated with insider risk, account misuse, or incomplete deprovisioning, scenarios that frequently evade purely event-based detection logic.

Understanding Blast Radius Before the Response

Once suspicious activity has been identified, the remaining challenge is decision-making, primarily understanding how to address the underlying cause and determining how to respond. Configuration data plays a central role here by revealing the permissions, policies, and trust relationships that shape potential impact, while runtime data grounds that assessment in what has already occurred.

Impact assessment starts with identifying what specifically enabled the activity. Runtime telemetry may show that a sensitive API was called or a protected resource was accessed, but the configuration context explains why that action was possible in the first place. This allows teams to respond surgically rather than broadly, by revoking a specific permission instead of disabling an entire identity, tightening a misconfigured policy rather than rotating every credential, or removing an OAuth scope that exceeds the application’s intended function. Without this level of configuration insight, response often becomes either overly disruptive or dangerously incomplete.

Similarly, blast radius assessment benefits greatly from this intersection of data. Runtime data shows which resources were accessed or modified, and configuration data reveals what else is reachable from that point. Role inheritance, delegated permissions, and cross-account access paths determine whether suspicious activity is likely to remain contained or spread laterally. By modeling reachable instances, identities, applications, and data stores, security teams can assess not just what has been compromised, but what could be compromised next. This forward-looking view is essential for prioritizing containment and scoping investigations.

The Future of Threat Detection is Config- and Event-Based

Ultimately, security risk cannot be understood through configuration or runtime data in isolation. By allowing posture and behavior to inform each other across prioritization, detection, and response, security teams can move beyond static severity and noisy alerts toward a model grounded in real impact. In a rapidly evolving and complex environment, closing the gap between configuration and runtime is a prerequisite for effective security operations.