Digital Evidence

IP address, device and geolocation: how far can these data really identify the author of a transaction?

By Alan Badenas dos Santos · Published October 5, 2026 · 7 min read

Cover for the article on IP, devices and geolocation, featuring a location marker.
On this page

Abstract

IP addresses, device identifiers and geolocation are common elements in fraud reports and digital forensic examinations. They can be highly valuable, but none should be treated in isolation as civil identity or human authorship. Shared networks, Carrier-Grade NAT, VPNs, proxies, multi-user devices, fingerprinting limitations and differences among location sources can radically change the interpretation. This article proposes a correlation-based model, explains why a public IP without source port and precise timestamp may be insufficient under CGNAT, and distinguishes connection attribution, device attribution and person attribution.

Keywords: IP; CGNAT; device fingerprint; geolocation; attribution; digital evidence.

1. Three different questions are often collapsed into one

Three distinct levels of transaction attribution: network connection, device and person.
Figure 1 — Connection, device and person: three distinct levels of attribution

A statement such as “the IP belongs to the customer, therefore the customer performed the transaction” compresses three separate technical questions:

  1. Which network connection originated a communication?

  2. Which device or computing environment participated in the session?

  3. Which person was operating that environment at the relevant time?

An IP address may assist with the first. A combination of device attributes can strengthen the second. The third usually requires authentication, possession, behavior and contextual evidence.

Forensic precision depends on keeping these levels separate.

2. What an IP address actually represents

CGNAT diagram linking IP address, port, timestamp and protocol when examining a connection.
Figure 2 — CGNAT: why IP, port, time and protocol may need to be correlated

An IP address identifies a logical network endpoint, not a person. In a simple residential scenario, a public IPv4 address may be temporarily associated with a subscriber; even then, many users and devices can share it through a router.

With Carrier-Grade NAT (CGNAT), the issue becomes more significant. IETF documents describe environments where one public IPv4 address is shared by multiple subscribers. Attribution of a specific connection may require public IP + source port + timestamp + transport protocol, correlated with provider records.[1][2][3]

RFC 6888 explains the need to identify subscribers through external address, port and time. RFC 6302 recommends that Internet-facing services record source ports and accurate timestamps precisely because address sharing exists.[1][2]

Therefore a report containing only a public IP may be insufficient to individualize a connection.

3. Time is part of the identifier

Addresses and ports are reused. Timestamps are therefore not cosmetic metadata.

IETF guidance highlights accurate timekeeping in shared-address environments. Clock differences between an application and a provider can create ambiguity in subscriber attribution.[3][4]

A forensic review should establish:

  • time zone;

  • UTC versus local time;

  • timestamp precision;

  • millisecond resolution when relevant;

  • time synchronization source;

  • known clock drift;

  • event-generation versus event-storage time;

  • any later normalization.

A log may look precise while supporting a weak inference if its temporal semantics are unknown.

4. IP attribution is not necessarily human attribution

Even when a public connection is correctly mapped to a subscriber, the meaning remains limited.

One connection can serve a household, office, hotel, shop, IoT devices, remote sessions, virtual machines or a compromised endpoint. VPNs and proxies may cause the IP observed by the service to belong to an intermediary.

A more defensible statement is that observed traffic was associated with a particular network connection or infrastructure — not automatically that person X performed the act.

5. Device fingerprinting: often probabilistic identity of an environment

Anti-fraud systems frequently use device fingerprinting to recognize or re-identify a browser, device or environment through combinations of observable characteristics.

Possible signals include operating-system and application versions, model, screen properties, language, time zone, browser capabilities, persistent app identifiers, graphics characteristics, network features and previously issued tokens.

W3C describes browser fingerprinting as identifying or re-identifying a user, user agent or device using configuration settings or observable characteristics, while also highlighting significant privacy implications.[5]

A key forensic point follows: a “fingerprint” is not necessarily an immutable physical serial number. Depending on implementation, it may be a probabilistic and partially mutable classification.

6. What to ask about a “device ID”

The term device ID is not technically self-explanatory. An examiner should determine:

  • who generates it;

  • at which layer it exists;

  • whether it survives app reinstall;

  • whether OS updates change it;

  • whether it depends on cookies/local storage;

  • whether it is derived probabilistically;

  • whether it includes cryptographic binding;

  • whether the server can verify its provenance;

  • whether it can be copied or replayed;

  • whether historical mappings are retained.

Two systems may use the label “device ID” for mechanisms with completely different evidentiary properties.

7. A known device is not the same as a known user

A device repeatedly used by an account holder is relevant context. But the disputed event still requires analysis.

The device may have been borrowed, stolen, remotely controlled, infected, used during social engineering, accessed under coercion or re-enabled through account recovery.

Thus, “same device + same network” may increase consistency with prior behavior without eliminating alternative explanations.

8. Geolocation: which technology produced the location?

Comparison of geolocation sources and the different attribution meanings of their data.
Figure 3 — Geolocation sources and their different evidentiary meanings

“Location” is not one type of evidence. It may originate from:

  • GNSS/GPS sensors;

  • cellular-network estimation;

  • Wi-Fi positioning;

  • IP geolocation databases;

  • user-declared address information.

Accuracy varies substantially. IP geolocation may indicate a city or region without identifying a precise physical point. GPS may be far more precise, but collection permissions, integrity and spoofing must be considered.

A coordinate without source, accuracy estimate, timestamp and acquisition method has limited forensic meaning.

9. Multi-signal correlation is stronger than single-signal attribution

Attribution becomes stronger when independent indicators converge: historically associated device, strong authentication, familiar network, compatible location, no recent credential reset and transaction-specific cryptographic approval.

Divergences may be equally informative: new device, unprecedented location, password reset minutes earlier, new beneficiary, VPN/datacenter IP or unusual session sequence.

A rigorous examination should test competing hypotheses rather than select only the indicators that support one narrative.

10. Preservation and auditability

Correlation is trustworthy only when the underlying data can be audited.

ISO/IEC 27037 addresses identification, collection, acquisition and preservation of digital evidence.[6] NIST SP 800-86 provides a structured forensic workflow.[7]

For IP, fingerprint and geolocation data, useful questions include source, schema, units, retention, architecture changes, export procedure, filters, integrity and documentation of any algorithm producing derived risk labels.

A field such as device_risk = low is itself a system conclusion. A forensic evaluation may need the inputs and rule set behind it.

11. Better expert questions

Instead of “does the IP belong to the author?”, ask:

  • was the address public, private or CGN-shared?

  • was the source port retained?

  • what is timestamp precision?

  • can address, port and time be mapped to a subscriber?

  • what attributes form the device identifier?

  • is the identifier deterministic, cryptographic or probabilistic?

  • had the device appeared previously on the account?

  • which technology produced the location?

  • what accuracy was reported?

  • do the available signals converge or materially conflict?

These questions move the analysis from apparent certainty to actual evidentiary quality.

12. Conclusion

IP, device fingerprint and geolocation can be powerful digital-investigation signals, but each has a defined scope. IP helps attribute traffic to network infrastructure; fingerprinting helps recognize an environment; geolocation estimates or measures position according to a specific technology. None, by itself, equals human authorship.

The strongest conclusions arise from correlation among network, device, authentication, session, transaction and context. Scientific transparency increases when the report distinguishes what was measured from what was inferred.

In digital evidence, precision is not simply a matter of exact numbers. It means knowing exactly what each number represents.

12A. Attribution as an inferential ladder

A mature attribution opinion should state separately what supports attribution of a network connection, what supports association with a device or computing environment, and what additional evidence supports inference about the human operator. ISO/IEC 27042 and ISO/IEC 27043 provide useful methodological references for documented analysis and incident-investigation processes.

References

  1. IETF.

    RFC 6888: Common Requirements for Carrier-Grade NATs

    . https://www.rfc-editor.org/rfc/rfc6888

  2. IETF.

    RFC 6302: Logging Recommendations for Internet-Facing Servers

    . https://www.rfc-editor.org/rfc/rfc6302

  3. IETF.

    RFC 6269: Issues with IP Address Sharing

    . https://www.rfc-editor.org/rfc/rfc6269

  4. IETF.

    RFC 7422: Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments

    . https://www.rfc-editor.org/rfc/rfc7422

  5. W3C.

    Mitigating Browser Fingerprinting in Web Specifications

    . 2025. https://www.w3.org/TR/fingerprinting-guidance/

  6. ISO/IEC.

    ISO/IEC 27037:2012

    . https://www.iso.org/standard/44381.html

  7. NIST.

    SP 800-86

    . https://doi.org/10.6028/NIST.SP.800-86

  8. NIST.

    SP 800-63-4

    . 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final

  • ISO/IEC.

    ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence

    . https://www.iso.org/standard/44406.html

  • ISO/IEC.

    ISO/IEC 27043:2015 — Incident investigation principles and processes

    . https://www.iso.org/standard/44407.html

Editorial note: attribution in a specific matter depends on the actual architecture, source records and hypotheses in dispute.

Alan Badenas

Discuss this content

Discuss this content