Notifications
Clear all
Topic starter
06/07/2026 9:44 am
TL;DR: Leaked-credential checks and IOC enrichment can now be built into login flows so teams can block or step up access before account takeover, using threat intelligence from dark web sources and breach data, according to Descope. The real shift is that authentication decisions become risk-aware, not just password-aware.
NHIMG editorial — based on content published by Descope: Expose hidden threats at login with Descope and Bitsight TI connectors
By the numbers:
- ATO fraud caused over $15 billion in losses in 2024.
- In 2024, more than 80 percent of breaches involved indicators of compromise that could have been identified and acted on beforehand.
Questions worth separating out
Q: How should security teams use leaked-credential checks in login flows?
A: Security teams should run leaked-credential checks before access is established and use the result to decide whether to allow, challenge, or block the login.
Q: Why do external threat signals matter for account takeover prevention?
A: External threat signals matter because many account takeover attempts are not visible from the login form alone.
Q: What do teams get wrong about MFA in high-risk login scenarios?
A: Teams often treat MFA as a universal answer when it is really a response mechanism.
Practitioner guidance
- Add breached-credential checks to the pre-authentication path Check email addresses, usernames, or domains against breach intelligence before the session is established so compromised identities can be challenged or blocked early.
- Use IOC context to drive adaptive challenge decisions Enrich IPs, domains, and hashes associated with login attempts with threat intelligence and feed the result into step-up authentication, denial, or additional verification.
- Separate trusted-user convenience from high-risk access handling Keep the default login experience fast for low-risk users, but route exposed credentials, high-risk infrastructure, and anomalous patterns into stronger checks.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the Bitsight connector is wired into Descope Flows
- The exact flow logic for leaked-credential checks, step-up authentication, and access blocking
- IOC enrichment examples for IPs, domains, and hashes inside the login sequence
- How the connector pairs with other integrations such as Forter, Fingerprint, and Telesign
👉 Read Descope's analysis of threat intelligence at login and account takeover prevention →
Threat intel at login: what it means for IAM teams?
Explore further
06/07/2026 10:00 am
Credential intelligence at login is becoming a baseline identity control, not a niche fraud tactic. Authentication flows that ignore breached credentials and malicious infrastructure are making decisions with incomplete context. Once that gap exists, the login page becomes the wrong place to treat identity as a closed system. Practitioners should treat external threat intel as part of the access decision, not an enrichment reserved for SOC workflows.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how weak lifecycle governance remains.
A question worth separating out:
Q: Who should own threat intelligence inside customer identity workflows?
A: Ownership should sit with the identity and security functions together, because the control affects both access policy and threat response. Identity teams need to define when a login is challenged or blocked, while security teams need to maintain the signals and escalation logic. That shared ownership prevents the connector from becoming a disconnected security add-on.
👉 Read our full editorial: Threat intel at login changes how identity teams block account takeover
