The system of record that maintains itself.
Grant one read-only role and Omnitam discovers your cloud estate agentlessly, 84 AWS resource types across 30 services, classifies it into a CMDB, maps every dependency, and writes each change to a tamper-evident audit trail, kept up to seven years. No agents. One read-only IAM role. Core features on every paid plan; Enterprise adds business-unit tenants.
Everything the baseline CMDB should have been.
The core platform is a complete, self-maintaining inventory, with scan cadence and history depth set by plan. Not a spreadsheet you reconcile by hand: discovery keeps the record current, and your owners decide the exceptions.
Agentless, read-only discovery
One IAM role you create, list/describe/get only, external-ID protected against confused-deputy attacks, revocable anytime. Nothing installed on a single host.
84 AWS resource types
Across 30 AWS services, connected by 47 relationship types. Compute, storage, networking, databases, security, and more, enumerated continuously.
Discovery scan cadence
Hourly on Essential, near real-time on Standard and above. Change shows up in the record on your plan's clock, not a quarterly sweep.
Dependency mapping
Every resource's upstream and downstream relationships, derived from discovery and kept current, so blast radius and ownership are a query, not an investigation.
Topology visualization
See the dependency graph, not just the list. Resources render as a topology: nodes, depends-on and runs-on edges, grouped by VPC and account, so blast radius is something you point at.
CMDB classification
Assets and configuration items classified into a coherent, queryable model with ownership rules, a CMDB that stays true because discovery maintains it.
Reconciliation & findings
Discovered resources are checked continuously against the live cloud: duplicate records sharing a fingerprint (cloud ARN, certificate thumbprint, or license key) and discovery drops, where a resource vanishes between sweeps, are both detected, with drill-down to the affected records. Owner-reported duplicates and source mismatches become findings with a resolve lifecycle and a mean-time-to-reconcile.
Recertification
Ownership and access are recertified on a schedule: owners confirm what is still theirs, a duplicated item converges to one open attestation per cluster instead of one per copy, and any discrepancy an owner reports flows straight into reconciliation as a finding.
Capture history
One year of change history included on every plan; extend it to 3, 5 or 7 years with the data-retention add-on. Every prior state of every asset, preserved and queryable.
Tamper-evident audit trail
Every change recorded in write-protected storage: who, what, when, and the value it replaced. Kept in hash-chained batches, and it can't be changed in normal operation.
Certificate lifecycle tracking
Every certificate tracked to the day it expires, with early alerts, so a renewal is a calendar item, never a 2 a.m. outage.
Scheduled reports
Inventory, ownership, and compliance posture generated on a cadence and emailed straight to recipients, including your auditor. Evidence, on a schedule.
On-demand exports
Export any view whenever you need it, in CSV, JSON, PDF, or XLSX. Hand a working paper to an auditor or a dataset to a downstream system in seconds.
Separate tenants for business units (Enterprise)
Isolate divisions and departments at the data layer. Subsidiaries and business units stay separate; teams stay granular; roll-ups stay whole.
API-first & Terraform-native
Everything above is scriptable over an OpenAPI 3.1 surface, with scoped keys and Terraform-native onboarding. Adoption without a migration project.
Reconciliation vs. recertification.
They ask different questions, run on different clocks, and produce different evidence, upstream data quality and downstream ownership attestation, and they feed each other.
| Dimension | Reconciliation | Recertification |
|---|---|---|
| Question it answers | Does the record match what's actually running? | Is this asset still owned, and is the assignment still correct? |
| Who acts | Discovery detects; an owner or reviewer resolves the finding. | The assigned certifier, usually the asset's owner, attests. |
| Unit | A duplicate-record cluster (shared fingerprint), a discovery drop, or an owner-reported finding. | One attestation task per asset; a duplicate cluster converges to one open task, not one per copy. |
| When | Continuous, as discovery runs and owners report a mismatch. | On a set cadence (for example, quarterly). |
| Output | A live view of duplicate clusters and discovery drops, drilling down to the affected records, plus owner-reported findings that stay open until resolved (resolution note, mean-time-to-reconcile). | A decision: confirmed, confirmed with changes, transfer, retire, or waived. |
| Place in the flow | Upstream: is the inventory itself accurate? | Downstream: is the accurate inventory still assigned correctly? |
Discrepancies become findings
When an owner reports a duplicate record or a data-source mismatch while recertifying, it becomes a reconciliation finding with its own resolve lifecycle, not just a note buried in one recert cycle.
Recertification is duplicate-aware
Records that share a fingerprint show their siblings alongside the attestation task, so an owner isn't asked to confirm the same asset once per copy.
Resolution closes the loop
Resolving a finding is tracked independently of the recert cadence, so reconciliation's open/resolved counts and mean-time-to-reconcile reflect data quality on their own clock.
Point at the blast radius.
Dependency mapping, drawn. Every resource is a node; every depends-on and runs-on relationship is an edge, grouped by VPC and account, and current because discovery keeps it so.
The core, tier by tier.
History starts when collection is enabled; Omnitam cannot show state from before an account was connected.
A record that maintains itself.
Discovered, not entered
The inventory is built by continuous discovery against your live account. There is no manual data-entry step to fall behind reality, so it never goes stale between audits.
Owned, end to end
Ownership rules and transfers keep every asset and configuration item chargeable to a team, with a dependency map that shows exactly what each one touches.
Provable, for up to seven years
Every change lands in a write-protected, tamper-evident trail and can be exported on demand or emailed on a schedule, the evidence a SOX, ISO 27001, or SOC 2 control asks for.
About the core.
What access does discovery need?
A read-only IAM role you create in your own account, list/describe/get only, protected by a unique external ID against confused-deputy attacks, and barred from reading secret values. No agents, no inbound network access, revocable by you at any time. Every session is visible in your own CloudTrail.
How many resource types, and which clouds?
84 AWS resource types across 30 services today, connected by 47 relationship types and scanned as often as near-real-time. Additional clouds are on the roadmap; software running anywhere is covered by SBOM ingestion.
What makes the audit trail tamper-evident?
Audit evidence is kept in write-protected, tamper-evident storage for up to seven years on paid tiers while you are a customer, and can be exported for auditors (SOX, ISO 27001, SOC 2). It can't be changed in normal operation. Personal data can still be erased on request. Need point-in-time reconstruction and time-diffs on top of that? See Time Machine.
Is any of this manual to keep current?
Not the inventory. Discovery keeps the record current and checks it continuously against your real cloud. People still decide the exceptions: you set ownership rules and alert routing once, and owners resolve the duplicates and mismatches that discovery cannot settle.
See your estate discovered before the hour is out.
Connect one AWS account, read-only, nothing installed, and watch the inventory, dependencies, and evidence build themselves.