Behind Actionability: The Axonius Asset Intelligence Pipeline

Action depends on truth. Truth is hard to come by.

Before you can automate a response, enforce a policy, apply a control, or deploy a patch, you must be confident in the data driving those decisions. Detection logic, access rules, and remediation playbooks are only as effective as the context they operate on. And today, that context is often unreliable – fragmented across tools, inconsistent between systems, and often stale by the time it’s needed.

With AI now being layered into modern security workflows, the risk of acting on bad data is amplified. For better or worse, AI treats inputs as ground truth. If the underlying data is misleading, it scales the wrong decisions faster.

Viewed through a security lens, the concept of a context window becomes literal. The old trope, “you can’t protect what you can’t see” now extends into the realm of action: “AI automates what it sees." If the context window contains conflicting assets, mismatched fields, or outdated telemetry, the model may hallucinate asset state, misinterpret relationships, or trigger the wrong actions.

This is the data challenge that Axonius has been tackling since our inception. Our market-leading Adapter Network bi-directionally integrates with over 1,200 sources (as of writing this blog), fetching asset and configuration data from every corner of the enterprise. 

But it’s far more than an integration catalog. Turning raw, noisy, and overlapping data into a complete, accurate, and always up-to-date model of your entire IT environment is hard. This post walks through the Axonius Asset Intelligence pipeline – the data foundation of our entire platform.

Assess: Surface coverage gaps, exposures, misconfigurations, and other findings based on prebuilt and custom rules

The Axonius Asset Intelligence Pipeline

The bar we set for our underlying data is decision-grade output. Each stage in this pipeline solves a specific class of data engineering problems that static inventories, vuln scanners, SIEMs, and CMDBs are unequipped to handle.

The Axonius Asset Intelligence Pipeline

• Collect: Ingest raw asset and system configuration data from integrated sources using a highly parallelized adapter framework

• Correlate: Match entities across systems using flexible, field-aware heuristics

• Normalize: Apply schema-level logic and deconfliction rules to standardize fields and eliminate noise

• Enrich: Add relevant context from external sources to complete asset profiles

• Model: Structure a continuously updated graph of relationships across assets by type

Stage 1: Collect

The discovery process via adapter connections

Every security tool claims to “discover” assets. But continuously collecting the right data from the right systems in the right way is far from trivial.

• Every source has its own schema, authentication flow, and quirks (paging, rate limits, throttling, etc.)

• Some APIs return incomplete records (i.e. vuln scanners without MACs or hostnames)

• Many asset types don’t show up in traditional discovery systems (ephemeral cloud resources, BYOD, Unmanaged SaaS Apps, etc.)

Our hypothesis is that a select number of control planes in your IT stack represent the totality of your environment when effectively aggregated. Completing that picture is the crux of this pipeline, and it starts with collecting data via Adapters. 

The Adapter framework is designed to fetch system and asset data from every integrated source – endpoint services, cloud platforms, identity providers, security tools, SaaS apps, and more. APIs were the inflection point that enabled this architecture, transforming once-static tools into live sources of truth. Each Adapter is engineered to match the nuances of its source system:

• Handle all connection logic (auth, session management, endpoint discovery)

• Fetch raw asset data at configurable intervals

• Translate inconsistent data formats into a structured intermediate representation

• Annotate all records with freshness indicators, source identifiers, and metadata for downstream correlation

• Gracefully handle API errors, timeouts, and rate limits with retry and backoff strategies

Discovery is a continuously scheduled operation to match how frequently your environment changes without overwhelming source systems – configurable globally, per adapter, or even per connection. Each cycle runs in parallel, multi-threaded, and batched for scale, with built-in monitoring to detect and handle failures. For urgent needs, discovery jobs can also be triggered on demand. Per-adapter diagnostics show exactly what data was fetched, when, and from where, to support traceability, auditing, and debugging.

Every Adapter instance’s fetch history is logged with assets discovered by type

The result is a high-fidelity ingestion layer that establishes the baseline for the entire pipeline with fresh, structured system and asset data.

Stage 2: Correlate

Complete set of correlation steps taken in sequence

Raw system data is messy. Correlation is the process of resolving which data actually represents an asset across tools. 

• The same asset may show up in multiple systems with conflicting values (hostname vs FQDN, internal vs external IP, multiple usernames, etc.)

• Some sources lack persistent identifiers (i.e. cloud resources with changing instance IDs or vuln scans without hostnames)

• Field values like “last seen” or “OS type” can differ depending on source and time of collection

Correlating too aggressively merges distinct entities. Under-correlating leads to conflicting records. But deduplication isn’t simply a cleanup task – it’s a real-time decision engine that has to resolve every asset at scale, while in flight, and with imperfect data.

At Axonius, correlation and deduplication go hand in hand. Once all raw records are collected during the global discovery cycle, we evaluate every entity using a rules-based correlation engine. The goal: reduce thousands of overlapping inputs into a single, authoritative asset profile.

• Correlation rules are field-aware and tailored to each adapter – prioritizing stable identifiers like MAC address, hostname, serial number, domain, and user ID

• We apply a confidence-weighted scoring model, with source-level trust hierarchies (i.e. AD and ITAM are considered high-fidelity; vuln scanners are noisy and low-trust)

• The system avoids correlation on unstable fields like IP address unless explicitly configured

• Multiple records from different sources are merged into a single asset, but with source-level field provenance retained

All correlation outcomes are logged and inspectable. The Axonius platform surfaces merge histories and field conflicts at the asset level. This not only increases trust, but provides a path to validation, debugging, refinement, and continuous improvement. 

Correlation steps across Adapters are detailed with every Discovery Cycle

The result is deduplicated, unified profiles across many distinct asset types – clean enough to trust, structured enough to query, and rich enough to power everything downstream.

Stage 3: Normalize

Example normalization process across mismatched field names and values

Even after the correlation stage, asset profiles can get messy in their own right. Different systems may use different field names, formats, and values, even when they’re describing the same thing.

• One system reports Windows Server 2016 Std, another says Microsoft Windows Server 2016 Standard Edition, and a third just says 2016 STD 10.0.14393

• MAC addresses may show up as mac, MACAddress, nic_address, or buried inside nested JSON blobs

• Timestamps like last seen or last checked in can appear under different field names or formats across systems

Normalization in Axonius isn’t a one-time cleanup job – it’s a continuous process applied during every discovery cycle. Some normalization happens at collection time to support correlation, but the heavy lifting comes once asset entities are resolved.

Here, we map inconsistent, vendor-specific field names to a common internal schema that spans device, user, software, identity, and policy attributes. That schema is versioned, extensible, and applied uniformly across every adapter. 

• Adapter-specific mappings translate raw fields to Axonius common fields during ingest

• Value normalization transforms variants of common fields (i.e. OS names, status enums, date formats) into canonical representations

• We maintain a library of normalization logic for edge cases, vendor-specific quirks, and known inconsistencies

• Fields are evaluated during reaggregation to identify and consolidate duplicate values

• All normalized data retains links to the original raw source, enabling traceability and audit

Preferred Fields in an Asset Profile view represent the result of the normalization process

Without normalization, querying would be guesswork. You’d have to know every possible variant of every value, field, and format across systems. With normalization, you can ask a question once and get a consistent answer.

Stage 4: Enrich

Example set of enrichment fields applied to an asset profile from various sources

Once assets are fully correlated and normalized through the Adapter Network, you gain a clean view of every asset and its state. In many ways, this is enough to uncover coverage gaps, fix misconfigurations, address exposures, and optimize inefficiencies. External forces, however, have an impact on what that state means in day-to-day operations:

• Is this installed software End-of-Life?

• Is that device affected by the latest 0-day?

• Does this SaaS app meet our compliance requirements?

• Is this admin account part of a data breach?

That’s where enrichment comes in – layering in external context to make otherwise static data operationally meaningful for specific use cases. But it comes with its own set of challenges.

• Data formats, identifiers, and field names vary wildly across enrichment sources, requiring custom parsing, vendor understanding, and transformation

• External feeds like CVEs and EOL datasets update frequently, requiring regular sync and validation

• Over-enrichment can degrade performance or create noisy, low-signal data unless carefully scoped

Enrichment in Axonius complements our Adapter architecture. Adapters provide deep, bi-directional integrations with the control planes of record, pulling asset and system data directly from the source and enabling actions in return. External sources enhance what we already know, rather than stand in for what we don’t.

The enrichment process is applied after correlation and normalization, once a unified asset profile exists. 

• Enrichment sources are matched to asset records using normalized fields like software name, version, domain, or app identifier

• Select asset attributes such as Vulnerability: CVE Severity, Software:End of Life, or SaaS:Compliance are injected directly into the asset profile as fields

• Enrichment data is refreshed at regular intervals to reflect changes in threat intel, vendor status, or risk scoring

Some enrichment sources originate from third-party data feeds; others are maintained directly by Axonius. For example, we maintain a proprietary SaaS Application Repository that includes risk assessments, compliance indicators, and functional categorization for over 2,000 applications. 

The SaaS Applications Repository is an enrichment source maintained by Axonius

Stage 5: Model

Methods of modeling relationships between assets

With complete, accurate, and up-to-date asset profiles across types, the next stage is understanding how they relate to reflect the real structure of the total environment – users to devices, software to vulnerabilities, identities to applications, and more. Real world environments never fit into a single schema, however.

• Relationships are fragmented across systems, and must be resolved across domains 

• Many associations are implicit, not explicitly defined

• Relationship accuracy depends on timing and freshness 

• Attack paths cross boundaries requiring traversal awareness across layers

• Modeling must scale across millions of relationships without creating brittle chains 

We operate under the belief that meaningful relationships across domains can be derived from a select number of control planes – the core systems that manage identity, endpoints, and  infrastructure to name a few. These systems define how assets are connected, governed, and exposed. When aggregated, they reveal the true structure of the environment.

Axonius builds an inferred model of these relationships using the structured, normalized data already collected during the discovery and enrichment stages. These relationships are continuously updated to reflect current topology, policy scope, and exposure reach across domains.

Some relationships are more obvious to infer than others, such as mapping applications to users through IdP assignments. A few “aha” examples include:

• Mapping public IPs to internal assets by analyzing firewall and load balancer configurations

• Mapping unmanaged SaaS apps by comparing expense reports to SSO configurations

• Mapping orphaned assets by identifying infrastructure assets that lack ownership metadata from the CMDB

• Mapping excessive spend by identifying SaaS licenses that are attached to disabled users in the HRIS

• Mapping policy drift by comparing on-device state with MDM reports

An Asset Graph representing assets publicly exposed

These modeled relationships allow Axonius to see the global attack surface from both the inside out and the outside in – so that when you ask us a question, you can be confident that you’ll get the truth in return.

Stage 6: Assess

Example calculation - a user’s total effective permissions across all systems and applications

This is where frontend exploration begins. From this point on, every data point resulting from this pipeline is consumable through queries, dashboards, and API. But assessments are only as good as the context they operate on – turning raw data into reliable signals requires engineering across systems.

• Evaluating posture requires joining conditions across identity, device, cloud, and app domains

• Many exposures only surface when multiple attributes combine under the right conditions

• Permissions, coverage, and configuration states often conflict across sources and must be reconciled

• Environmental differences like tagging schemes, naming conventions, and control settings impact how posture is assessed

• Risk definitions vary by organization, making static scoring insufficient without contextual awareness

Every stage of the pipeline so far culminates in a unified dataset that’s ready for actionable assessment. This is what enables Axonius to smartly evaluate risk, performance, and cost measures based on truthful, cross-domain context – not the isolated, fragmented data that originated from individual sources. 

Assessment logic runs directly on this unified asset model, where all normalized fields, relationships, and enrichment data are queryable in real time.

• Relationships between assets are traversed to assess coverage, access, or risk.

• Filters and joins allow conditional evaluations

• Findings are computed continuously, not batch-scanned, so results reflect live context

This data shows up in a number of ways across the Axonius platform – via queries, dashboards, findings, graphs, and more. It’s always a major focus of our roadmap investment to bring more out-of-the-box answers in more intuitive, user-friendly ways.

Dashboards in Axonius are the anchor for transforming visibility into actionability

What makes this especially powerful isn’t just asset data – it’s also the ability to combine asset context, business context, and threat context in one model. That means assessments can factor in real organizational impact, not just theoretical exposure, prioritizing what matters most to the business, not just what matches a signature.

Making Asset Intelligence Your Asset Intelligence

Asset intelligence isn’t one-size-fits-all. Every organization has its own nuances – naming conventions, ownership rules, tagging strategies, business units, and compliance guidelines to name a few. Even the set of configured adapters can dramatically shape how the pipeline behaves. Whether you're a single-cloud or multi-cloud shop, using Okta or EntraID as your IdP, relying on one EDR or five – those choices impact how assets should be discovered, correlated, and assessed.

Axonius is built to flex around your environment, and we provide a number of ways to tune the data pipeline to your liking:

• Custom Correlation Rules: Define how assets are matched and merged across sources using flexible field weighting

• Custom Enrichment: Inject internal knowledge or external intelligence into asset profiles using static, dynamic, or derived fields

• Data Transformations: Clean, convert, or extract values inline to standardize data across systems

• Custom Fields: Extend the schema with attributes that matter to your business, such as asset owner, data classification, or lifecycle stage

• Field Mapping Overrides: Override default interpretations to better align incoming data with your internal definitions

By shaping the pipeline to fit your reality, Axonius ensures that asset intelligence is tailored to drive action in your world. 

And your world continuously changes. Assets are in constant motion – spinning up, shutting down, changing states, or shifting ownership. Asset Intelligence must capture how your environment changes over time.

Axonius records every discovery cycle as a snapshot of your environment at that moment. As a result, you always have a complete view of your entire environment at any given time. At a granular level, every asset comes with a built-in changelog, capturing what fields were added, removed, or modified across time.

Asset Investigation displays field-level changes – representing an asset changelog

Time as a first-class citizen in the Axonius platform is one of the many reasons why Asset Intelligence is more than just an asset inventory. Time represents change, change involves drift, drift requires investigation.

Conclusion

Modern security teams are on a valiant quest for operational force multipliers – do more with less, act faster with confidence, and scale efforts without scaling headcount. But real leverage doesn’t start with automation. It starts with context.

This is the foundation Axonius builds. A pipeline purpose-built to turn raw, conflicting, and incomplete data into a unified, action-ready model of the environment – the whole environment. Every stage is engineered to make context reliable, so decisions, policies, and automations are based on truth.

Force multipliers demand action. In our next post, we’ll dive into how Axonius transforms asset intelligence into intelligent action. Welcome to the Actionability Era.