A device graph is a data structure or service that links multiple devices, browsers or apps to the same person or household. Attackers and ad-tech systems use it to correlate behaviour across contexts, so defenders should validate matching logic, limit linkable identifiers and control the privacy impact of any identity resolution.
What a device graph does
A device graph is an identity-resolution data model that connects devices, browsers, and apps to a shared person or household profile. It is useful because it turns scattered interaction records into a relationship map, but that same linkage can also increase privacy sensitivity and reduce user anonymity.
Device graphs are usually built from signals such as login events, cookies, SDK identifiers, IP patterns, and shared network or behavioural features. The quality of the graph depends on how confidently those signals can be matched, and whether the underlying assumptions still hold as users switch devices, reset identifiers, or share hardware.
How device graphs are used in security and advertising
In ad-tech, a device graph helps systems recognise the same household or person across sessions so they can measure reach, frequency, attribution, and audience overlap. In security contexts, the same correlation logic can help spot suspicious account behaviour, but it can also create a broader profile than the user expected if linkable identifiers are too permissive.
Because the graph connects contexts that were originally separate, it effectively becomes a high-value inference layer. A weak matching rule can merge unrelated people, while an overly strict rule can fragment a single user into many partial identities. Both failure modes distort downstream decisions, including targeting, analytics, fraud review, and privacy controls.
Matching logic and identifier governance
The central technical question is not whether a graph exists, but how it decides that two records belong together. Matching logic should be explainable, testable, and constrained by purpose, because hidden or opaque correlation rules make it difficult to challenge false links or understand why a profile exists.
Identifier governance matters just as much. Systems should limit which identifiers can be linked, reduce unnecessary persistence, and separate highly sensitive signals from broad behavioural data. Where possible, matching should rely on the minimum information needed to support the use case, rather than on broad tracking by default.
Privacy impact and control boundaries
Device graphs can amplify privacy impact because they make cross-context profiling easier, especially when the graph spans multiple products, vendors, or data sources. Even when the input signals are individually ordinary, the combined profile can reveal habits, associations, location patterns, or shared household activity that users would not reasonably expect to be unified.
That is why device graph design should be treated as a privacy boundary, not just a data engineering exercise. The key control question is whether the organisation can justify the correlation, explain the matching basis, and prevent the graph from becoming a default surveillance layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST Privacy Framework and NIST SP 800-53 Rev 5 set the technical controls, and GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Article 5 — Principles relating to processing of personal data | Device graphs correlate personal data across contexts and must follow purpose and minimisation principles |
| Article 25 — Data protection by design and by default | Device-graph matching and identifier scope should be designed to reduce unnecessary privacy exposure | |
| Recommendation — Limit correlation to a justified purpose and minimise linkable identifiers in the graph. Build privacy limits into matching logic, retention, and identifier selection by default. | ||
| NIST Privacy Framework | Data processing and privacy risk management functions | Device graphs are privacy-risk tooling because they infer and link identities across contexts |
| Recommendation — Assess the privacy impact of cross-context linking and constrain identity resolution to the stated use case. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Device graphs are governed systems that should restrict who can query or export linked identity data |
| Recommendation — Restrict access to device-graph outputs and downstream correlation data to approved roles. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Analysts and systems should only access the portions of the graph needed for the approved use case |
| Recommendation — Limit access to graph data and correlation outputs to the minimum required scope. | ||
| OWASP API Security Top 10 | API3 — Broken Object Property Level Authorization | Graph services often expose profile attributes and link fields that need property-level authorization |
| Recommendation — Enforce property-level authorization on device-graph attributes and link metadata. | ||
Practitioner Guidance
Why practitioners should care: A device graph is only as trustworthy as its matching criteria. Teams should validate whether the graph is being used for legitimate measurement or whether it has drifted into broad identity resolution that exceeds the original purpose.
What to watch for: Pay attention to excessive identifier reuse, hidden third-party correlation, and unexplained profile growth across devices or households. Those are common signs that the graph is linking more data than the business case requires.
Practitioner takeaway: Treat device graphs as governed correlation systems, not neutral lookup tables, and keep the privacy impact tied to the minimum useful linkability.