The meter is a perpetual thorn in your side
Ask an analyst why an alert went without enrichment, and the answer is probably: it wouldn’t have hurt, but….
The lookup had a price, and the price only felt worth paying on alerts that already looked bad. So teams ration. They enrich the handful of indicators that already smell wrong and leave the rest, never knowing if that enrichment context was the missing piece of a malicious signal puzzle.
This problem is not new. We’re far from the first to impose it, but we want to be the first to solve it.
Censys is introducing Unlimited Enrichment, a host enrichment API that doesn’t draw down your credit balance. This blog will cover how Unlimited Enrichment works with real-life examples to help you get started.
How Censys Unlimited Enrichment works
External context should be a bedrock layer that sits under every workflow, not a scarce resource you spend carefully. Consumption-metered tools like VirusTotal train teams to treat enrichment as expensive, so it arrives late, on a fraction of alerts, and usually inside one vendor’s console.
By contrast, with Censys, “Unlimited” means exactly that. You can stop rationing lookups.
Censys Unlimited Enrichment is a credit-free host enrichment API that returns a compact, standardized profile for any IPv4 or IPv6 address, built for high-volume automated lookups in SIEM, SOAR, and AI SOC pipelines. It exists so the first question every analyst asks about an external IP (how much should I care?) gets a fast, evidence-backed answer at the front of the workflow instead of the end of it.
It returns a compact, standardized profile of what Censys sees on that host right now:
- Geolocation
- Network and ASN ownership
- Forward and reverse DNS
- Open ports and protocols
- Device and service labels
- Censys ARC Reputation Score
- Detected threats
- Third-party context from GreyNoise, IPinfo, Mallory.ai, and more
We’d rather you pull Censys context in at the very front of triage, on everything, and carry it wherever the work goes next. It’s portable data that every team can reuse, and built for automation, unlike others who offer unlimited action in their web interface only.

Diving deeper
The design is simple: one lightweight endpoint, an IP in, a fixed JSON object out. The response is small and always the same shape, so it’s cheap to ingest into a SIEM and predictable to parse in a playbook. Hundreds of additional fields are available with a follow-up call if needed.
In a single lookup you get:
- Ownership and network: WhoIs organization and network name, ASN number/name/description and BGP prefix, and geolocation down to the city.
- Naming and surface: forward DNS (
host.dns.names), reverse DNS, totalhost.service_count, and the ports and protocols observed. - Classification: host- and service-level labels such as
REMOTE_ACCESS, DATABASE, andOPEN_DIRECTORY. - Risk: the Reputation Score, its score level, and the evidence categories that produced it.
- Threats: the detected threat name, type, and tactic wherever Censys observed offensive tooling or malicious infrastructure on the host.
- Third-party context: GreyNoise classification and actor; IPinfo hosting/mobile/satellite flags; and privacy signals for VPN, proxy, Tor, relay, and anonymizer.
Authentication is the same credential you already use for Censys, so this drops into an existing SOAR or SIEM integration without new plumbing. The payload is compact and standardized, which keeps it cheap in two directions: fewer bytes to store and index, and far fewer tokens when the alert is being read by a model instead of a person. An AI SOC that starts from a tight, structured Censys profile spends less to reach a better decision than one handed a raw IP or a full host dump.
Unlimited Enrichment is the quick glance. When the glance says look closer, the rest of the platform is the deep dive: credit-based actions for the full host detail, CenQL for complex querying, MCP server and CLI for investigation, and Collections with webhook push when you want to engineer detections and feeds.
Four alerts, four faster verdicts
Example time! The pattern is the same across your tools: an alert names an external IP, and the analyst needs a defensible read before spending real attention on it. Here’s how one enrichment call reshapes the first minute of each.
Firewall: an outbound session into the Great Unknown
Your NGFW logs an outbound connection from a server segment to an external IP on an unusual port. It’s on no blocklist, so it’s sitting in the maybe pile. Enrich the destination and read the risk and threat blocks first.
If the threat block names a framework (say, “Vshell”, the Chinese-Language alternative to Cobalt Strike) or the score is Malicious with command-and-control evidence, you’re containing the internal host and blocking the destination, not opening a ticket to think about it.
If it resolves to a clean, well-known CDN or SaaS provider with a benign score, you close.
For everything in between, you evaluate all thirty-nine fields of context, and take action or investigate deeper with a full lookup.

| host.autonomous_system.name | HWCSNET – Huawei Cloud Service data center |
| host.location.country | China |
| host.services.threats.name | VShell |
| host.services.threats.type | C2_SERVER |
| host.reputation.evidence.category | command_and_control_offensive |
| host.reputation.score | 100 |
| host.services.protocol | HTTP |
| host.services.port | 3333 |
| host.services.protocol | HTTP |
| host.services.port | 8084 |
| host.services.protocol | HTTP |
| host.services.port | 9876 |
| host.services.protocol | RTSP |
| host.services.port | 9999 |
| host.services.protocol | HTTP |
| host.services.port | 12345 |
EDR: a process beacons out, menacingly!
Your EDR flags a suspicious process on a workstation making periodic callbacks to an external host, the shape of beaconing. Enrich the callback IP and the reputation evidence may settle it: a host.services.threats.name such as one of the AsyncRAT relatives, or a command-and-control evidence category, turns a “suspicious process” into an active-C2 case. Isolate the endpoint.

| host.location.city | San Jose |
| host.location.country | United States |
| host.whois.network.handle | PT-82-5 |
| host.whois.network.name | PEG TECH INC |
| host.services.port | 8000 |
| host.services.protocol | GHOST |
| host.services.threats.name | Ghost RAT |
| host.services.threats.type | C2_SERVER |
| host.services.threats.tactic | COMMAND_AND_CONTROL |
| host.reputation.score | 0.82 |
| host.reputation.score_level | MALICIOUS |
| host.network.hosting | true |
| host.privacy.anonymous | false |
| host.privacy.tor | false |
| host.privacy.relay | false |
| host.privacy.vpn | false |
Bonus points: from there, pivot through the platform to find the rest of the cluster, and stand up a Collection with a webhook so new infrastructure in that cluster pushes to you as it appears.
DLP: data leaves to an unsanctioned endpoint
Your DLP flags a large upload from an endpoint to an external destination that isn’t sanctioned. The question is whether that destination is boring corporate infrastructure or somewhere data should never go. Enrich it and read ownership and classification together: host.whois.organization.name and host.autonomous_system.name, host.network.hosting, labels like OPEN_DIRECTORY / FILE_SHARING / NAS, plus host.location.country and the Reputation Score.
A destination that geolocates to an unexpected country, sits on a random hosting ASN, and exposes an open directory is a possible exfil endpoint. Escalate.
One that maps cleanly to a known cloud provider’s ASN with a benign score is a policy conversation, maybe even an attack surface exposure.
Either way, the analyst starts with useful context instead of a bare IP.
| host.services.labels.value | FILE_SHARING |
| host.services.labels.value | REMOTE_ACCESS |
| host.services.labels.value | DATABASE |
| host.location.city | Lille |
| host.location.country | France |
| host.autonomous_system.bgp_prefix | 51.91.X.X/16 |
| host.services.port | 21 |
| host.services.protocol | FTP |
| host.services.port | 1801 |
| host.services.protocol | MSMQ |
| host.services.port | 3306 |
| host.services.protocol | MYSQL |
| host.services.port | 3389 |
| host.services.protocol | RDP |
IAM: a sign-in from somewhere new & scary
Your IdP (Okta, Entra) flags a successful login for a privileged account from an IP outside the user’s normal geography and ASN. The question quickly shifts from “is this the user?” to “what kind of network is this login coming from?”
Enrich the source IP and let the privacy and network fields answer it, alongside the Reputation Score.
A login from a mobile carrier on a residential-type ASN with a benign GreyNoise read looks like a user who traveled — close it faster. A login from a datacenter ASN with hosting = true and a proxy or VPN flag, especially with an elevated score, is a step-up-auth-and-escalate. If it escalates, investigate deeper with getHost/CenQL for the full service picture.

| host.privacy.vpn | true |
| host.privacy.proxy | true |
| host.privacy.tor | false |
| host.network.hosting | true |
| host.network.mobile | false |
| host.reputation.score | 52 |
| score_level | Medium Risk |
| host.autonomous_system.name | HOSTKEY-AS – HOSTKEY B.V. |
| host.location.country | Netherlands |
The layer under everything else
Unlimited Enrichment is a credit-free host enrichment API, built for high-volume automated lookups. It returns a standardized profile
Censys isn’t trying to be your SIEM, your EDR, or your threat intel program. It’s the ground-truth layer that makes those systems sharper. It’s most useful when it’s everywhere: on every alert, across every team, and priced so nobody has to ration it. Get the context in early, carry it downstream, and spend your attention and tokens on more complex investigations.
Unlimited Enrichment is an option on the Censys Core plan. See what else Censys Core can do for you, or request a demo to pit it against your own alerts.

