Topic starter
23/06/2026 7:09 pm
TL;DR: IP addresses are public identifiers tied to devices and locations, which makes them useful for connectivity but also exposes privacy and targeting risk, according to DigiCert. For identity teams, the issue is less about finding an address and more about deciding what trust, telemetry, and controls should follow from it.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “How Can I Find Out My IP Address?”.
Key questions
Q: How should security teams use IP addresses in access decisions?
A: Use IP addresses as contextual evidence, not as proof of identity.
Q: Why do public IP addresses create security risk even without a breach?
A: Public IP addresses can expose location, hosting patterns, and reachable services, which gives attackers useful reconnaissance data.
Q: What signs show that IP-based trust is failing?
A: Common warning signs include access rules that break when users move networks, frequent exceptions for VPNs or remote workers, and repeated reliance on source address as a fallback trust factor.
Practitioner guidance
- Classify IP address data as contextual telemetry Document where public and local IP data is collected, which systems consume it, and which decisions it is allowed to influence.
- Review access rules that rely on source IP Check whether location, network range, or ASN information is being used as a proxy for trust in remote access, admin access, or fraud controls.
- Reduce unnecessary IP retention in logs and analytics Keep only the IP-derived data needed for troubleshooting, threat detection, and compliance, then remove the rest from long-lived stores.
Bottom line: IP address visibility is operationally useful, but it does not establish identity or trust on its own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:01 am
IP visibility is not trust. A public IP address tells you where traffic appears to originate, not whether the subject is legitimate or authorised. Identity programmes that treat location as proof of trust create a brittle control model that can be bypassed, misread, or overextended. The practical conclusion is that IP should remain contextual metadata, never a substitute for identity assurance.
A question worth separating out:
Q: Should organisations trust network location or identity assurance first?
A: Identity assurance should come first. Network location can improve risk decisions, but it is too unstable and too easily obscured to carry the main trust burden on its own. Organisations should use location as one part of a layered control set, then anchor access decisions in verified identity, device state, and session risk.
👉 Read our full editorial: IP address visibility and network trust in identity security