What an IP reputation score actually measures

"Reputation" is a borrowed word and it carries the wrong intuition. A person's reputation is about who they are. An address has no character. All you ever have is a record of behaviour observed from somewhere, at some point, by someone, plus a guess about how much that record should influence what you do with the next packet.

Once you look at it that way, the useful questions get sharper. Who observed it. How recently. How many independent observers. What did the address actually do, and what would it cost you to be wrong.

The four inputs

Our scoring engine moves a score on four things.

Severity. A single TCP connection to a closed port is not the same as a credential stuffing run against a VPN portal, and neither is the same as an exploit attempt against a known CVE. A firewall that already classified the event has done half the work, which is why sensor integrations read threat logs rather than raw flows.

Frequency. Persistence separates a misconfigured client from a campaign. One failed authentication is noise. Four hundred across nine hours, spread across your address range, is intent.

Third party intelligence. External feeds still matter, mostly as corroboration. They are slow relative to live telemetry, but when an address is already known to several reputable sources it raises confidence in a signal you are only beginning to see yourself.

Community signal. This is the input you cannot buy, and it is the reason the platform is shaped the way it is. The same address hitting one honeypot once is weak evidence. The same address hitting a dozen unrelated networks inside an hour is a different claim entirely, and it is a claim no single organisation can make about its own logs.

None of these are decisive alone. The score is what you get when you weigh them against each other, continuously.

Your signals and everyone's signals

When you set up a threat sensor you decide whether it contributes private signals, public signals or both, and you can change that afterwards.

Private signals stay inside your account. They feed your own score database and your own lists, and are never shared with other customers. Public signals join the shared pool, which is what makes the community input above exist for everybody, including you.

Sensible defaults look different depending on what a device sees. A honeypot has no legitimate traffic by construction, so everything it records is interesting to everyone and there is little reason not to share it. A perimeter firewall in a regulated environment is a more careful conversation, and the answer is often to contribute publicly from the honeypot and privately from the firewall. That is a legitimate configuration, not a half measure.

Scores have to decay

A score that only goes up is a countdown to a support ticket.

Cloud addresses are recycled constantly. The address that ran a scan on Tuesday can be fronting a startup's staging environment by Friday. Compromised hosts get cleaned. Misconfigured clients get fixed. If nothing pulls a score back down, your list accumulates entries that were once correct and are now just damage waiting for the right customer to hit it.

Every blocklist has a check interval, in hours, that controls how often blocked addresses are re scored and removed when they no longer clear the threshold. It is the least glamorous setting in the product and the one I would argue about hardest. Addition is what vendors demo. Removal is what decides whether you still trust the list in six months.

What a score cannot tell you

A high score says an address behaved badly where someone could see it. It does not say a single thing about who is behind it, and a few structural facts make that gap wider than people expect.

Carrier grade NAT puts thousands of mobile subscribers behind one address. Block it and you have blocked a chunk of a mobile network, most of whom have never heard of you. Shared hosting and CDN nodes have the same shape: one address, many tenants, one of whom is a problem. Cloud egress addresses are worse still, because the same address can carry a customer's API traffic and someone else's scanner within the same minute.

In the other direction, residential proxy networks route attacks through consumer broadband lines that look exactly like your customers, because they are your customers' neighbours. And a genuinely targeted attack against your organisation may consist of one connection from one address with no history anywhere.

So reputation scoring removes the automated majority. It will not stop the thing that was built for you specifically, and a product that claims otherwise is not being straight with you.

Picking a threshold

Start high, watch, then lower. That ordering is the entire method.

A high public threshold on a new list gives you a small set of addresses with strong multi source evidence. Point a firewall at it in log only mode for a week, read what it would have dropped, and look for anything you recognise. Then take the threshold down a step and repeat. Somewhere along that curve you will find the point where the log starts containing things you have to think about, and the right threshold is just above it.

Private (RFC 1918) and public addresses get separate thresholds on the same list precisely because the evidence is different in kind. A private address that scores is almost always something of yours that is compromised or misconfigured, and the correct response is usually an investigation rather than a drop rule.

Reading a score in practice

When an address you care about shows up, three questions sort out nearly every case. Did our own sensors see it, or is this purely community and third party evidence. How recently was the most severe event. And is the address in a range that structurally shares itself, meaning CGNAT, shared hosting or cloud egress.

That last question is the one that catches people out, and it is cheaper to ask before you write the rule than after a partner calls.

Next in this series: how large a blocklist should actually be, and why the biggest list is rarely the best one.