Pulseguard
Under Attack?Asset Inventory
Every domain and server, in one place.
Domains, subdomains, DNS records, certificates, and detected technologies, consolidated into one view that updates itself every time a scan runs. No spreadsheet to maintain, and no asset that quietly stops being tracked.
- Asset classes tracked
- 4
- Manual entry required
- 0
- Refresh cadence
- Every scan
- Discovery history
- Immutable
Everything you expose, in one list.
Filter by what you're actually looking for. Each row carries where it was discovered, so you can tell an asset someone registered from one the crawler found on its own.
You can't protect what nobody wrote down
Most breaches start on the asset nobody remembered was still running. An inventory that maintains itself is the only kind that stays true.
Found, not filled in
Assets arrive from the crawler, the DNS resolver, and the TLS handshake, not from a form somebody has to remember to update after a launch.
Discovery source on every row
Each asset records how it was found. A subdomain that turned up in DNS but was never in anyone's plan is exactly the row worth a second look.
One consolidated read
Domains, technologies, DNS records, and certificate history in one place instead of four screens: the same data the rest of PulseGuard scores and monitors.
The third parties too
Technology fingerprinting names the CDN, the payment processor, and the analytics running on your pages, so your supply chain is part of the inventory rather than an assumption.
Nothing is overwritten
Assets are appended and timestamped, never replaced. First-seen and last-seen dates make it possible to answer when something appeared, not just whether it exists now.
Feeds everything else
The inventory isn't a separate silo. It's the same domain, DNS, and certificate records that SSL Monitoring, DNS Monitoring, and the scanner all work from.
Four classes of asset, one record
Each class comes from a discovery mechanism that already runs as part of a scan, which is why the inventory costs nothing extra to keep current.
Domains and subdomains
The primary domain plus everything discovered under it, each with its verification state and last successful response.
DNS records
A, AAAA, MX, TXT, NS, and SOA records resolved per domain and stored with their TTLs and first-seen dates.
Technologies
Frameworks, CDNs, analytics, and payment providers identified from response headers, HTML signatures, and known JS globals.
Certificates
Issuer, subject, validity window, and protocol version captured on every scan, kept as history rather than a single current value.
How the inventory builds itself
Nothing here is a separate job you schedule. Every asset is a by-product of work the scanner is already doing.
- 1
The crawler maps what's reachable
Starting from your primary domain, a bounded breadth-first crawl records pages and assets, respecting robots.txt, your configured depth and page limits, and the scan scope you set on the project.
- 2
DNS and TLS fill in the rest
Records are resolved directly for each domain, and the certificate presented on every TLS handshake is captured: the parts of your footprint no crawler can see by following links.
- 3
Fingerprints name the stack
Response headers, HTML signatures, and known JS globals are matched against a signature set to identify what's running, so 'Next.js behind Cloudflare with Stripe on checkout' is recorded rather than inferred later.
- 4
Changes land on the timeline
Each scan diffs against the previous one. A new subdomain, a dropped technology, or a rotated certificate becomes an event you can read in order, not a silent update to a row.
Asset Inventory, answered.
No, and that's deliberate. Asset Inventory is a consolidated read over data the scanner, DNS resolver, and TLS checks already collect. Nothing extra runs against your infrastructure just to populate a list.
Find out what's actually running.
Add a domain and the first inventory is populated by the end of the first scan.