Is the Security Graph ever going to be brought back?

Over six years ago, Microsoft explored the concept of a Security Graph, with the vision of bringing together insights from across the security ecosystem into a unified relationship-driven platform. The goal was to connect security data, signals, and intelligence from multiple vendors to provide deeper visibility, context, and understanding of complex security environments. Over time, much of this effort was consolidated into the broader Microsoft Graph strategy, which emphasized centralized data access and integration. While that approach delivered significant benefits, the emergence of AI and graph-based intelligence highlights the value of domain-specific models where relationships are intentionally defined, preserved, and analyzed rather than inferred after the fact.

I believe the time has come for Microsoft to revisit and revive the concept of the Security Graph. While I understand the rationale behind consolidating security data into centralized platforms to simplify implementation and improve accessibility, the rapid advancement of AI has demonstrated the value of specialized models with purpose-built relationships and context.

A dedicated Security Graph would provide significant advantages by explicitly defining relationships between security entities, events, controls, assets, identities, and findings rather than relying solely on correlation and inference. This approach would enable deeper analytics, more accurate investigations, enhanced threat detection, and improved decision-making across the security ecosystem.

However, the framework should evolve beyond traditional log aggregation and align with the operational data that security vendors already generate. Each security assessment, validation, or monitoring submission should include structured metadata describing:

1. The objective of the capability or validation being performed.
2. The methodology used, including specific tests executed and the environments, controls, and assets evaluated.
3. The toolset details, including product name, version, identity or service account used, supporting datasets, and systems interacted with during testing.
4. Findings and observed results.
5. Coverage gaps, including tests not completed, areas not evaluated, and data not analyzed.
6. The underlying raw logs and telemetry currently generated and submitted by the tool.

To ensure integrity and accountability, all submissions should be cryptographically signed, providing verifiable evidence of who performed the assessment, when it was performed, and what data was collected.

With this richer, evidence-based data model, a Security Graph could be constructed that not only enables security teams to trace activities, relationships, and attack paths with greater confidence, but also provides substantial value for risk management, governance, compliance, and audit functions. The resulting graph would move beyond simple event correlation to become a trusted system of record for continuous security validation, assurance, and accountability.

Thoughts???