The autonomous CMDB. Discovers, reconciles, and corrects itself.
Kovira is an autonomous CMDB - a Configuration Management Database that maintains itself. It discovers assets, reconciles them into one accurate record per real-world thing, corrects drift without a human in the loop, and stays in step with the environment continuously. The result is a living configuration record for IT teams, sysadmins, IT consultants, and MSPs who need a CMDB that reflects the network today rather than the picture from the last audit.
What is an autonomous CMDB?
An autonomous CMDB is a Configuration Management Database that runs itself. It discovers assets, reconciles them into one accurate record per real-world thing, corrects drift without human intervention, and surfaces changes the moment they happen. Where a traditional CMDB asks the team to be the accuracy mechanism, an autonomous CMDB makes accuracy a property of the system itself.
Autonomy is the operating model; live is the property the user sees. Every autonomous CMDB is a live CMDB. The team stops curating records and starts approving the small set of consequential changes that genuinely need a human - everything else stays accurate on its own.
- Self-discovering. The CMDB finds new assets without anyone telling it where to look.
- Self-correcting. When discovery and the existing record disagree, the system resolves it.
- Self-reconciling. Three discovery surfaces seeing the same asset become one CI, not three.
- Self-explaining. Every autonomous change is captured in the version history, so reviewers see what the system did and why.
Manual, automated, autonomous
CMDBs are not all alike. The difference between a stale spreadsheet and a living configuration record is a difference in operating model. An autonomous CMDB sits at the top of the spectrum because the system, not the team, owns accuracy.
Manual CMDB
The team is the accuracy mechanism. Records get updated when somebody remembers, or during a periodic cleanup project. Drift is permanent.
- Spreadsheets
- Wiki pages
- Untouched ServiceNow CI tables
Automated CMDB
Discovery scripts run on a schedule and dump data into the CMDB. Faster than manual, but the team still owns reconciliation, conflict resolution, and stale-record cleanup. Drift slows but doesn't stop.
- Cron-driven discovery
- One-way sync from MDM
- Imports from a CSV export
Autonomous CMDB
The system discovers, reconciles, deduplicates, and corrects without a human in the loop. The team approves consequential changes; everything else stays accurate on its own. Drift is a system property the platform fixes, not a backlog item.
- Kovira
- Continuous reconciliation across discovery sources
- Self-healing CI graph
What makes a CMDB autonomous
Six traits separate a CMDB that runs itself from one that just runs scripts. Together they describe the operating model behind a living configuration record.
Self-discovering
An autonomous CMDB finds assets without anyone telling it where to look. New devices on the network, new endpoints joining the fleet, new identities in the directory - they show up in the configuration record because the system noticed, not because someone filed a ticket.
Self-correcting
When discovery and the existing record disagree, the autonomous CMDB resolves the difference on its own. Updated attributes flow through, decommissioned assets get a last-seen timestamp, and the record converges back to ground truth. Humans see the audit trail; the system does the work.
Self-reconciling across sources
Three discovery surfaces seeing the same machine become one CI, not three. The autonomous CMDB maintains the cross-source identity model itself - the team never sits in front of a merge queue cleaning up duplicates.
Self-routing into workflows
When the configuration record changes, downstream automation reacts - workflows fire, incidents open, change reviews see new dependencies. The CMDB is not a passive store; it is the trigger surface for the rest of the platform, and that linkage runs without intervention.
Self-explaining
Autonomy is only safe when it is observable. Every change the CMDB makes on its own is recorded in the version history of that CI, so reviewers can see what the system did, when, and based on which signal. Autonomy without an audit trail is a black box; autonomy with one is leverage.
Smart, not just busy
Discovery alone is noise. Autonomy is the layer that turns that noise into a coherent record - inferring relationships, suppressing transient blips, weighting more reliable sources, and flagging genuinely new behaviour. The CMDB earns the autonomy by being right more often than the team would have been by hand.
What is a live CMDB?
A live CMDB is the visible result of an autonomous operating model: a Configuration Management Database that is current, continuously, without human upkeep. The phrase distinguishes modern, self-maintaining configuration databases from the traditional CMDB - the spreadsheet, the half-completed ServiceNow tables, the IT Glue docs that decay between audits.
In a living CMDB, accuracy is a property of the system rather than a habit of the team. In an autonomous one, the system also handles the work of keeping it that way - discovery, reconciliation, drift correction, conflict resolution - so nobody on the team needs to remember to do it.
- Continuous, not periodic. Records update as the environment changes, not on an audit schedule.
- Reconciled across sources. A single asset seen by multiple discovery surfaces becomes one CI, not three.
- The trusted record. Workflows, change reviews, incident triage, and compliance all run against it.
Traditional CMDB vs live CMDB
The defining difference between a traditional CMDB and a live CMDB is who is responsible for keeping it accurate. In a traditional CMDB, that is the team. In a live CMDB, that is the system.
How records get updated
- Traditional
- Manual entry, periodic audits
- Live (Kovira)
- Heartbeat from automated discovery (instant with LIVE add-ons)
Update cadence
- Traditional
- Whenever someone remembers
- Live (Kovira)
- Minutes to hours on the heartbeat, push-on-change with LIVE
Time to drift
- Traditional
- Weeks to months
- Live (Kovira)
- Stays current as the environment changes
Single source of truth
- Traditional
- Coexists with shadow spreadsheets
- Live (Kovira)
- The record everyone actually uses
Change-window blind spots
- Traditional
- Updates only if someone remembers
- Live (Kovira)
- Picks up new and removed devices automatically
Cross-source records
- Traditional
- One asset becomes three records
- Live (Kovira)
- Reconciled into one record per asset
Confidence at audit time
- Traditional
- Depends on recent cleanup
- Live (Kovira)
- Always reflects what is on the network
Workflow + automation reliability
- Traditional
- Brittle - drives off stale data
- Live (Kovira)
- Workflows fire against current state
Cost of ownership
- Traditional
- High - human maintenance is the product
- Live (Kovira)
- Low - the CMDB maintains itself
Operating model
- Traditional
- Manual: the team is responsible for accuracy
- Live (Kovira)
- Autonomous: the system is responsible for accuracy
Audit trail of CMDB changes
- Traditional
- Whatever someone wrote in the ticket
- Live (Kovira)
- Every autonomous change recorded in the CI version history
What the team spends time on
- Traditional
- Cleaning up the CMDB so it can be trusted
- Live (Kovira)
- Working from a CMDB that is already trusted
Heartbeat and reflex
A living CMDB has two speeds. The heartbeat is the steady pulse that keeps it alive. The reflex is the instant response when something needs to land in the record now. Both feed the same CMDB.
Heartbeat
Included in every planThe continuous pulse. ATLAS keeps endpoint records current; VECTOR keeps the network record current; the Microsoft 365 surface keeps directory, devices, and policy posture current. Tuned to your environment automatically; you never set an interval by hand.
- ATLAS: endpoint posture, hardware, and software inventory for every managed device.
- VECTOR: network discovery with topology and L2 link enrichment so the CMDB knows what is plugged into what.
- Microsoft 365: identity, devices, and the full Entra ID + Intune policy surface as a single CMDB record per tenant.
- Reconciliation: every signal feeds the same record. Duplicates self-heal; decommissioned assets get a last-seen timestamp rather than rotting in place.
Reflex
Optional LIVE add-onsThe instant response. ATLAS LIVE and VECTOR LIVE surface environment changes in the CMDB near-instantly, layered on top of the heartbeat. For teams whose automations need to react in seconds rather than continuously.
- ATLAS LIVE: endpoint posture, software, and inventory changes surface near-instantly.
- VECTOR LIVE: network changes land in the CMDB as the scanner sees them.
- Same CMDB: reflexes layer on top of the heartbeat. Everything still feeds one record per asset.
- When you need it:security workflows that fire on posture drift; MSPs who want a tenant's network change in their console immediately.
The honest version: the base heartbeat is continuous, not instant. For most IT teams that is fast enough that the configuration record is always trustworthy. For teams whose automations need to react in seconds rather than continuously, LIVE adds the reflex layer on top of the same record.
Why traditional CMDBs go stale
CMDB drift is not a discipline problem. It is a structural one. A traditional CMDB needs people to keep it accurate, and people lose to whatever is on fire.
Reality moves faster than documentation
A switch goes in during a late-night change window. A laptop gets swapped. A subnet gets reorganised. Every change is an opportunity for the CMDB to slip out of step with the environment, and a traditional CMDB has no way to catch up on its own.
Manual upkeep loses to real work
When updating the CMDB is a checkbox at the end of a ticket, it is the first thing skipped when something is on fire. Within months the CMDB stops being the source of truth and starts being the artefact that nobody trusts.
Stale data quietly poisons everything
Impact analysis, change approvals, incident triage, audit evidence - they all assume the CMDB is right. When it is not, workflows fire against the wrong CIs, dependency maps mislead, and decisions get made on an out-of-date picture of the environment.
What makes a CMDB “living”
Calling a CMDB “live” is easy. Keeping one alive is harder. These are the properties a CMDB needs in order to actually deserve the name.
A heartbeat, not an audit cycle
A living CMDB observes the environment continuously rather than relying on a quarterly audit to refresh itself. Records change as the environment changes - a continuous pulse rather than a weekly batch.
Self-healing across every discovery source
A living CMDB reconciles signals from multiple discovery surfaces into a single accurate record per asset. The same machine seen by the network, the endpoint, and the directory does not become three records to clean up later - the CMDB heals the duplicates itself.
Change-aware by default
When the environment moves, the CMDB notices and updates, and the workflows that depend on the CMDB pick up the change without anybody routing a ticket. The configuration record is the trigger, not an afterthought.
The trusted record, not a copy
A living CMDB is the source of truth - everything else, from incident triage to compliance reporting, runs against it. There is no shadow spreadsheet beside the CMDB because the CMDB is current enough that no one needs one.
What a live CMDB unlocks
An accurate CMDB is not the goal. It is the prerequisite. A live CMDB makes every downstream workflow trustworthy.
Impact analysis before any change
Change reviewers need to know what depends on what. An autonomous CMDB shows the current dependency graph rather than the one from the last manual review, so impact analysis reflects what is actually deployed.
Incident triage on real data
When something breaks at 2am, the on-call engineer should not be guessing whether the CMDB is current. A living CMDB makes the configuration record trustworthy enough to drive triage decisions on - no "is this still accurate?" lookup before the actual investigation begins.
Compliance and audit evidence
Auditors ask for a current asset register. An autonomous CMDB is one - permanently. The audit trail is generated continuously rather than reconstructed in a panic the week before the assessment, and every autonomous change has a recorded source signal.
MSP visibility across every tenant
MSPs maintaining many client environments cannot afford manual CMDB upkeep per tenant. An autonomous CMDB scales: every tenant workspace stays current automatically, so the MSP team works from accurate data per client without the per-client overhead.
Workflow automation that actually fires
Workflows that depend on stale CI data are worse than no workflows - they fire against the wrong assets. An autonomous CMDB makes automation safe to run because the trigger surface is current. The workflow engine and the CMDB are the same product, so reactivity is built in.
Onboarding a new IT team without an audit project
When a new sysadmin or MSP technician joins, an autonomous CMDB is their first day's onboarding doc. The system already knows the environment - they don't need to spend a quarter discovering it themselves.
Kovira: the autonomous CMDB built for ITSM
Kovira is an autonomous CMDB and an ITILv4-aligned ITSM platform in one product. The CMDB stays alive through continuous discovery from ATLAS and VECTOR, Kovira's built-in discovery surfaces, and feeds the same configuration record that incident management, change management, workflow automation, and audit reporting run against. Add ATLAS LIVE or VECTOR LIVE for reflex-speed updates when continuous isn't fast enough.
Because the CMDB runs itself, the rest of Kovira gets to assume it is right. Workflows fire on current state. Change reviews see real dependencies. Incident triage uses a configuration record nobody has to second-guess. The team does the judgement work; the platform does the toil.
Autonomy without observability is a black box, so every change the platform makes on its own is captured in the CI version history - what changed, when, and which signal triggered it. The autonomous loop is auditable per CI, reversible per change, and visible to anyone who needs to look.
Autonomous CMDB: frequently asked questions
The questions IT teams ask most often when evaluating an autonomous, living CMDB.
What is an autonomous CMDB?
An autonomous CMDB is a Configuration Management Database that runs itself. It discovers assets on its own, reconciles them into one record per real-world thing, corrects drift without a human in the loop, and surfaces changes the moment they happen. Where a traditional CMDB asks the team to be the accuracy mechanism, an autonomous CMDB makes accuracy a property of the system itself.
What is a live CMDB?
A live CMDB is a Configuration Management Database that stays accurate without manual upkeep. It is the visible result of an autonomous operating model: continuous discovery, automatic reconciliation, and a configuration record that reflects what is on the network today rather than a snapshot from the last audit.
What is the difference between an autonomous CMDB and a live CMDB?
They describe the same thing from two angles. "Live" is the property the user sees - the CMDB is current, all the time. "Autonomous" is the operating model that produces it - the CMDB does the work of staying current on its own. Every autonomous CMDB is live; an asset register that updates itself is by definition both.
What does it mean that the CMDB is 'living'?
A living CMDB has a heartbeat. Kovira's discovery surfaces (ATLAS for endpoints, VECTOR for the network) observe the environment continuously, reconcile what they see against the existing record, and update the CMDB in step with the environment. The same way a living thing has vital signs, a living CMDB has a measurable, predictable pulse.
What is the heartbeat, and what is the reflex?
Two layers of the same nervous system. The heartbeat is the steady cadence of base discovery - included in every plan and good enough that the configuration record is always trustworthy. The reflex is the optional LIVE add-ons (ATLAS LIVE and VECTOR LIVE) that push changes into the CMDB the instant they happen, for teams whose automations need to react in seconds. Both layers feed the same single record per asset.
How fast does the CMDB update?
Fast enough that the configuration record is always trustworthy. On the heartbeat tier the CMDB is continuously refreshed by discovery; on the reflex tier (LIVE add-ons) changes are reflected near-instantly. The exact cadence is tuned automatically to the size and pace of your environment - we don't expose specific intervals because the goal is for you to never have to think about them.
When do I need the LIVE add-ons?
When the time between a real-world change and the CMDB knowing about it has to be near-zero. Typical fits: security workflows that fire on posture drift; MSPs who want a tenant's network change to surface in their console immediately; teams running automation chains that depend on second-fresh inventory. For most IT teams, the heartbeat is enough; LIVE is the upgrade for teams whose workflows assume reflex-speed signal.
Is an autonomous CMDB the same as an AI-powered CMDB?
Autonomy and AI are related but not synonymous. AI features (correlation, anomaly detection, dependency inference) accelerate the autonomous loop, but the autonomous part is the operating model: the CMDB observes, decides, and corrects without waiting on a human approval queue. Kovira combines both - automated discovery as the base, smart reconciliation on top, and an explicit audit trail so the autonomy is observable rather than mysterious.
How is an autonomous CMDB different from a traditional CMDB?
A traditional CMDB is a manual system of record - accurate when someone keeps it accurate, stale the moment the environment moves faster than the people maintaining it. An autonomous CMDB closes that gap structurally. The system is responsible for accuracy, not the team, so the configuration record is current by default rather than current when someone gets around to it.
Why do traditional CMDBs go stale?
CMDB drift is structural. Environments change faster than people can document them: devices appear during change windows, software rolls out across the fleet, laptops get swapped, and someone is always meant to record it. When the update path is manual, it loses to whatever is on fire. Within a few months the CMDB no longer matches the network, and within a year nobody trusts it.
What is CMDB drift and how does autonomy prevent it?
CMDB drift is the gap between the configuration record and reality. Autonomy prevents it by removing the manual step. The CMDB is rebuilt against reality continuously - new assets are detected, decommissioned ones get a last-seen timestamp, attribute changes flow in automatically. There is no audit cycle to fall behind on because there is no audit cycle at all.
What makes Kovira an autonomous CMDB?
Kovira observes the environment through built-in discovery (ATLAS endpoints, VECTOR network, Microsoft 365 directory and Intune), reconciles every signal into one record per asset, and self-heals duplicates without human intervention. Workflows fire against the current state, change reviews see real dependencies, and the configuration record is the source of truth rather than a record to be reconciled with one.
Does an autonomous CMDB still need a human in the loop?
For accuracy, no - the autonomy handles that. For decisions, yes. Approvals on impactful changes, the policy of which signals to trust most, and the boundaries of automated workflows still belong to people. Autonomy removes the toil; it doesn't replace judgement. Kovira surfaces every autonomous decision in an audit trail so the human-in-the-loop knows what changed without having to dig.
Does a live CMDB replace my ITSM tool?
A living, autonomous CMDB is the data foundation underneath ITSM, not a replacement for it. Kovira is both - an autonomous CMDB and an ITILv4-aligned ITSM platform - so incident management, change management, and impact analysis all run against configuration data that is current rather than against records nobody trusts.
Is an autonomous CMDB worth it for small IT teams?
Small teams benefit the most. The smaller the team, the harder it is to dedicate someone to manual CMDB upkeep, and the more painful drift becomes. Kovira's free tier includes the full autonomous CMDB so a single technician can maintain a current configuration record without the operational overhead.
How does a live, autonomous CMDB help with change management and audits?
Change approvals, impact analysis, incident triage, and compliance reporting all assume the CMDB is right. When it is not, decisions are made on yesterday's picture of the environment. An autonomous CMDB removes that risk - reviewers see current dependencies, auditors see a record that matches reality, and incident responders trust what they are looking at.
Is the live CMDB included in every Kovira plan?
Yes. The autonomous, living CMDB - including ATLAS and VECTOR on the base heartbeat tier - is included in every Kovira plan, including the free tier. The LIVE add-ons (ATLAS LIVE and VECTOR LIVE) are optional reflex upgrades for teams who want push-on-change updates instead of continuous scheduled discovery.
What categories of asset does Kovira's autonomous CMDB cover?
Endpoints, servers, network gear (with topology and L2 link enrichment), users, groups, software, contracts, vendors, locations, racks, domains, APIs, passwords, and Microsoft 365 surfaces (Entra ID identity, Intune devices and policies). Every CI lives in one consistent schema with a full version history, so autonomous updates are auditable and reversible per change rather than per-record snapshots.
An autonomous CMDB you will never have to babysit
Kovira is launching soon. The autonomous, living CMDB will be included in every plan, including the free tier. Be first in line when registration opens.