IP reputation is a risk assessment for an internet address. It helps a system answer a practical question: given what is known about this source and the request it is making, how much trust should we extend right now?

That assessment is useful in login protection, API abuse controls, WAF enrichment, payment fraud review, incident response, and account security. It is not an identity check, and it should not be treated as permanent truth.

What goes into IP reputation?

Providers use different data and models. A defensible assessment usually combines several signal families.

Observed behavior

Direct observations are stronger than labels alone. Useful evidence includes scanning, credential attacks, exploit attempts, spam behavior, automated probing, botnet activity, or repeated contact with honeypot sensors. The target, attack family, and sequence can help separate intentional behavior from background noise.

Recency and repetition

An attack observed minutes ago should carry more weight than an isolated event from months ago. Repeated behavior across multiple windows or sensors generally supports higher confidence than one event.

Network and infrastructure context

ASN, provider, prefix, connection type, hosting, VPN, proxy, Tor, and residential-network attributes help explain how the address connects. They do not prove malicious intent. A cloud address may be a scanner or a legitimate webhook; a residential address may be a customer or a compromised device.

Confidence and corroboration

Strong systems expose why they trust the result. Multiple independent observations, consistent classification, recent behavior, and supporting infrastructure signals can increase confidence. Conflicting or sparse data should produce a more cautious outcome.

Customer context

Your application knows things an external reputation provider cannot: account history, transaction value, requested route, device continuity, customer allowlists, and the cost of a false positive. Reputation becomes most useful when combined with that context.

Score versus evidence

A numeric score is convenient, but it can hide important differences. Two addresses can receive the same score for very different reasons: one because of recent repeated attacks, another because of older or indirect signals.

For production use, look for:

• the recommended action;
• observed behavior and attack family;
• first- and last-seen times;
• recency and repetition;
• network and infrastructure context;
• confidence factors and human-readable reasons;
• guidance on how long to cache the result.

That evidence lets security tune policy, engineering log a stable decision, and support explain what happened. See The IP Reputation Black Box Problem for a deeper treatment.

How reputation becomes a decision

Reputation should support a range of outcomes:

Result and request context	Possible action
No current malicious evidence; routine request	Allow
Weak, stale, or ambiguous evidence	Monitor or rate-limit
Suspicious context on a sensitive action	Challenge or require step-up verification
Recent, repeated, high-confidence attack evidence	Block temporarily
Reviewed partner or customer exception	Allowlist with expiry

There is no universal threshold. The cost of interrupting a legitimate reader is different from the cost of approving a high-value account takeover.

Where reputation goes wrong

• Treating a VPN or country as malicious. Those attributes can raise scrutiny, but they do not establish behavior.
• Using stale results forever. IPs are reassigned and evidence ages.
• Blocking a whole network after one finding. Shared providers contain unrelated customers.
• Failing to record the reason. A bare score is hard to audit or dispute.
• Ignoring an exception workflow. Even good systems need reviewed allowlists and a way to correct false positives.

How FraudGuard approaches IP reputation

FraudGuard ACE v2 combines first-party honeypot observations with attack correlation, recency, infrastructure and network enrichment, geography, confidence factors, and customer policy. It returns explainable allow, challenge, or block guidance instead of asking the application to reverse-engineer a score.

You can check an IP publicly, review the ACE v2 API, or use the Offline Threat Database for local, high-volume enrichment.

The principle is simple: reputation is strongest when it shows its work.