Changes to SecureAuth Threat Service IP Risk Scores and Their Effect on Authentication

Version Affected: All

 

Overview

This article is a notice about a change in the IP risk scores returned by the SecureAuth Threat Service. On 15 October 2026 the third-party IP reputation feed behind the service began returning a new threat type against a large number of IP addresses, and addresses that had previously returned a lower score began returning scores in the High and Extreme risk bands. Nothing changed in the SecureAuth Identity Platform, in the Threat Service itself, or in any realm's configuration — only the reputation data the service reads.
 

In this article

• What changed
• The new threat type
• Where the change appears in the logs
• What this means for authentication

What changed

On 15 October 2026 the IP reputation feed that supplies the SecureAuth Threat Service added a new threat type, PSCN, and began returning it against a large number of IP addresses. Because the value forms part of the risk factor the provider calculates, the scores returned for those addresses rose, in many cases from a lower score into the High or Extreme bands.

The provider reviewed a sample of the addresses reported to it and confirmed that the elevated scores are correct under its updated scoring criteria. This is a deliberate change to how the provider scores risk rather than a data error, and affected addresses are expected to continue scoring in the higher bands.
 

The new threat type

PSCN stands for Port Scan. The provider defines it as an IP address found in port scan traffic directed at a set of high-risk ports and services, covering scans aimed at Bitcoin, building systems, published CVEs, FTP, fuel systems, home automation, honeypots, media devices, medical devices, network attached storage, printers, RDP, routers, SIP, Telnet, TOR, torrents, video devices, videogame services and VNC.

Several of those categories cover consumer and small-site equipment, so ordinary business and residential connections can carry the value without anyone at that site deliberately scanning anything — a shared or network-address-translated address only has to have been seen in port scan traffic once for the value to apply to everyone behind it. For the addresses reported to it, the provider confirmed that the increase came from association with a port scan risk signature, in one case specifically through its router detection logic.

Where an address carries more than one threat type, the values are returned pipe-delimited, for example PSCN|USGH.
 

Where the change appears in the logs

The risk score and the threat types returned for an address are recorded in the realm's debug logs. The new value appears there in the threatTypeDescription field, alongside the risk factor and the state the Analyze Engine moved to:

Current IP '<CLIENT-IP-ADDRESS>', risk factor '100' details - threatType:100, threatCategory:3,
threatTypeDescription:PSCN|USGH, threatCategoryDescription:Enterprise, ...
Result: true
'state_threat_service_Rule_<REALM-NAME>:VerifyIPState', goes to 'hardstop'
=== Analyze Engine ends at 'HardStopState' ===

What this means for authentication

This change only causes a notable problem where a realm's threat service rule is configured to block on the affected score range. Realms that send those scores to a multi-factor prompt, or to any other non-blocking action, simply act on the new score as configured — a user may be challenged for a second factor where they previously were not, but they can still authenticate.

Where the rule blocks, users connecting from an affected address see Hardstopped by Analyze Engine at login, having signed in normally from the same address in the days before. The realm is behaving exactly as configured; what changed is the score it is acting on.

The recommended response is to change the action on the threat service rule for the affected score range from Block (HardStop) to Prompt for MFA (TwoFactor). Affected users are then challenged for a second factor instead of being stopped outright, which keeps them able to authenticate while preserving the additional check the elevated score is asking for.

Two things to expect once the rule is changed:

• A user can remain blocked for a short time after the change. Re-test once the cache has cleared rather than immediately.
• Scores are dynamic. An address's score can fall again if a later update from the provider reclassifies it, so a rule loosened during this change is worth reviewing periodically.

If a particular address appears to be scored incorrectly, SecureAuth can raise it with the data provider for review. Open a support case with the address in question and the lookup output returned for it.
 

Special Considerations

The elevated scores can be worked around for a specific address with an IP allow-list rule, but how that rule is configured matters. An allow-list rule that simply bypasses the check replaces an unexpected block with no additional authentication at all, on an address the reputation feed is actively flagging. Configure the rule to force a multi-factor method rather than to skip authentication, and add an address to it only after validating that the user behind it is genuine.
 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.