OpenText Core Threat Detection Expands Microsoft Integrations in Azure Marketplace

OpenText’s Core Threat Detection and Response has taken a significant step toward tighter Microsoft alignment, with expanded integrations that position the product as a first‑class partner for Defender for Endpoint, Microsoft Entra ID (identity), and Microsoft Security Copilot—delivered through Azure and now broadly available via the Azure Marketplace and OpenText’s Cloud Editions lineup.

Background​

OpenText announced the next generation of its cybersecurity offerings earlier in 2025, introducing OpenText Core Threat Detection and Response as a central element of the OpenText Cybersecurity Cloud. The product is designed to combine behavioral analytics, unsupervised machine learning, and threat‑hunting services into an open XDR architecture that ingests telemetry from endpoints, identity systems, and third‑party security tools. OpenText has emphasized Azure as the primary delivery platform for the product and has published integration kits and an Azure Marketplace listing to ease deployment for Microsoft‑centric customers.
These developments were reaffirmed in October 2025 when OpenText expanded the availability of the product and highlighted deeper operational ties with Microsoft Security tooling—most notably Microsoft Defender for Endpoint, Microsoft Entra ID, and Microsoft Security Copilot—framing the move as a way to reduce alert noise and accelerate investigations.

---

What the new integrations actually bring​

Deep endpoint and identity telemetry fusion​

At the heart of the announcement is a strategy many security operations teams have wanted for years: fuse endpoint telemetry with identity context to produce higher‑confidence detections. OpenText claims its solution extends Microsoft Defender for Endpoint telemetry with behavior‑based indicators, and then enriches that signal with identity signals from Microsoft Entra ID to surface incidents that often evade signature‑based controls—credential misuse, lateral movement, early‑stage ransomware activity, and certain insider behaviors. This identity‑centric approach is critical for catching sophisticated attacks that hide in legitimate credentials.

Microsoft Security Copilot augmentation​

OpenText is positioning its product to feed Copilot for Security with richer, context‑aware signals—behavioral indicators and identity context—so analysts get more concise, higher‑confidence summaries and guided playbooks during triage. In practical terms this means the output delivered to a Security Copilot workflow should have fewer false positives and more actionable steps, accelerating mean time to respond. Microsoft’s own Security Copilot roadmap toward agentic, automated security workflows makes this an attractive point of integration for customers already experimenting with AI‑augmented SOC workflows.

Open XDR and the Threat Integration Studio​

OpenText’s Threat Integration Studio—advertised as the ingestion layer for external telemetry—lets organizations bring in data from non‑Microsoft sources (SIEMs, network tools, application logs, cloud services). The stated benefit is a single pane of glass for correlation and hunting across multi‑vendor fleets, while keeping Microsoft telemetry as the backbone for endpoint and identity signals. This opens a path for organizations that want Microsoft as the primary telemetry source but need to keep investments in other products.

---

Technical overview: what’s under the hood​

AI, behavior analytics, and “hundreds of algorithms” (vendor claims)​

OpenText describes the product as using a combination of unsupervised machine learning, behavioral risk scoring, and a large library of detection models. These marketing phrases are common in modern XDR offerings; they indicate a mixture of:

• anomaly detection models (to spot deviations from baselines),
• entity‑and‑user risk scoring (to prioritize alerts),
• correlation and story‑building engines (to join events into incidents), and
• natural‑language explanation layers (to translate findings into analyst‑friendly summaries).

These elements are consistent with how vendors reduce analyst toil, but the precise model architectures and training datasets are vendor proprietary and — absent independent testing — should be treated as claims rather than independently verified performance guarantees. OpenText’s public materials use “hundreds of AI algorithms,” which is a useful shorthand but not a performance metric.

Deployment model and data flow​

• The product is available via Azure Marketplace, simplifying procurement and subscription management for Azure customers. This also means data residency, routing, and network topology choices will be influenced by Azure architecture and tenancy.
• Telemetry ingestion typically happens via APIs and sensor integrations: Defender for Endpoint provides endpoint events, Entra provides identity/access events, and other connectors stream logs into OpenText’s ingestion layer.
• Once ingested, telemetry is correlated and scored; high‑confidence incidents are presented to analysts (and optionally forwarded into Security Copilot workflows for AI‑assisted response).

---

Why this matters: security operations gains​

Reduced alert noise, improved signal‑to‑investigation ratio​

One of the federation problems in modern SOCs is volume: too many alerts, too little context. By fusing endpoint behavior with identity context and applying behavioral scoring, OpenText aims to reduce noise and deliver fewer, more precise incident prompts to analysts. That outcome is the most practical, near‑term operational advantage for teams struggling with backlog and burnout.

Identity‑centric detections catch credential misuse earlier​

A disproportionate number of breaches today start with credential compromise or malicious insiders. Bringing Entra ID signals into detection logic lets an XDR system prioritize anomalies where user behavior is inconsistent with prior access patterns—exactly the sort of use case Ponemon and others highlight as expensive when missed. OpenText expressly links its product to tackling insider risk, citing industry research on the rising cost of insider incidents.

Better Copilot outputs = faster analyst decisions​

Feeding Copilot for Security with richer context—behavioral indicators, identity correlation, and incident storylines—should reduce the need for manual evidence collection during triage. Analysts can move from signal to containment faster when Copilot recommendations are based on cross‑source correlation rather than siloed alerts. Microsoft’s own Security Copilot enhancements are being designed for that expectation.

---

Critical analysis: strengths, limitations, and risks​

Strengths​

• Tight Microsoft alignment. For Azure and Microsoft‑centric enterprises, the native integrations reduce friction and accelerate time‑to‑value. Azure Marketplace availability lowers procurement barriers.
• Identity + endpoint fusion. Combining Entra ID with Defender for Endpoint telemetry is a clear operational win for identity‑forward threats and lateral movement detection.
• Open XDR posture. The threat integration studio promises continued investments in extensibility—important for mixed‑vendor environments.
• AI assistance for analysts. Copilot augmentation and natural‑language explanation layers can materially shorten investigation cycles when implemented responsibly.

Limitations and caveats​

• Vendor claims vs. independent verification. Statements such as “hundreds of AI algorithms” and reductions in false positives are marketing claims. Independent, third‑party evaluations or SOC‑level telemetry are required to quantify real-world improvements. These claims should be treated as vendor guidance until validated in a customer pilot. Flagged for caution.
• Data residency and privacy. Moving telemetry into cloud‑hosted detection systems raises data residency, retention, and compliance considerations. Azure tenancy choices and contractual clauses need review before deployment in regulated industries.
• Copilot dependence risk. AI‑augmented suggestions are only as good as the inputs. If integrations or enrichments are incomplete, Copilot outputs may omit crucial context. Organizations must maintain analyst oversight and enforce playbook reviews.
• Operational integration complexity. Even with marketplace availability, mapping existing SIEM workflows, ticketing systems, and custom telemetry into a new open XDR platform requires engineering work and process redesign. Implementation timelines and professional services costs must be factored.
• Model drift and maintenance. Behavioral models change as environments change. Without rigorous model monitoring and timely retraining, detection efficacy can degrade—an endemic risk for ML‑based security products.

---

How it compares: where OpenText fits in the market​

OpenText is positioning Core Threat Detection and Response as a comprehensive layer for Microsoft customers—competing in the same landscape as other XDR/MDR vendors that emphasize identity‑and‑endpoint fusion, such as Vectra and others who have also extended Azure and Microsoft detections. Vendors differ on detection depth, managed services, and integration breadth; OpenText’s long history in enterprise content and records management gives it an advantage in content‑centric use cases where file access and content governance intersect with security telemetry.
Key differentiators to watch:

• Vendor strength in identity signals (Entra ID integration here is a plus).
• Ability to ingest and normalize non‑Microsoft telemetry (threat integration studio).
• Depth of managed services and threat hunting offerings—OpenText offers services to support detection tuning and response.

---

Practical guidance for Windows administrators and SOC teams​

Pre‑deployment checklist​

• Inventory current telemetry sources and confirm available APIs for Defender and Entra.
• Define regulatory and data residency constraints; identify required Azure tenancy/region.
• Map existing SIEM and ticketing workflows to the planned OpenText ingest paths.
• Plan a scoped pilot that includes:
• representative endpoints,
• identity events,
• at least one non‑Microsoft telemetry source to validate the Threat Integration Studio.
• Assign an internal owner for model‑monitoring and false positive triage.

Phased deployment steps​

• Enable telemetry exports from Microsoft Defender for Endpoint and Entra ID into a designated staging tenant.
• Configure the OpenText connectors; validate ingestion and retention settings.
• Run parallel detection for 30–90 days: compare OpenText detections to your baseline SIEM alerts.
• Tune alert thresholds and playbooks; update ticketing automation to leverage Copilot recommendations where appropriate.
• Move into production in stages—start with high‑value business units and scale horizontally.

Operational best practices​

• Maintain human oversight: require analyst sign‑off on automated containment actions for at least the first 90 days.
• Measure KPI improvements: mean time to detect, mean time to respond, and analyst time per incident.
• Establish a model‑health dashboard to detect concept drift and false positive trends.
• Keep a change log for behavioral baselines—normal business changes (e.g., mergers, large hiring events) will affect model baselines.

---

Business and compliance considerations​

Integrating a cloud‑hosted AI detection platform into a Microsoft environment can yield ROI by preventing expensive incidents—Ponemon’s research puts the average annual cost of insider risk in the tens of millions, underscoring why identity‑centric detection is a high‑priority investment. But realizing ROI depends on disciplined deployment, tuning, and governance; the product alone will not produce savings without operational change.
Enterprises should also review contract clauses relating to:

• Data ownership and permitted uses of telemetry for model training,
• SLAs for detection service availability and support,
• Auditability and exportability of detections for compliance reporting.

---

Independent verification and the need for pilots​

OpenText’s statements about improved detection and alert reduction are compelling, but SOC leaders and CISOs should require proof in the form of:

• Side‑by‑side pilot results (before/after detection counts and MTTx metrics),
• Representative red‑team validation of identity‑centric detections,
• Clear SLAs and remediation commitments from OpenText for production incidents.

This cautious, evidence‑based approach limits exposure while enabling the organization to realize the product’s benefits in production conditions.

---

What to watch next​

• Expansion of Copilot agent functionality and third‑party Copilot connectors will materially change how AI workflows interact with XDR systems—OpenText’s advantage hinges on how quickly it can channel high‑confidence signals into those agentic workflows.
• Additional telemetry sources beyond endpoint and identity (cloud workloads, SaaS app telemetry, IoT) will raise the bar for any vendor claiming a comprehensive XDR posture.
• Independent testing labs and customer case studies that quantify false positive reduction and MTTx improvements will be decisive for broader adoption.

---

Conclusion​

OpenText’s expanded Microsoft integrations represent a practical and strategic move: for Microsoft‑centric enterprises, native Defender, Entra, and Security Copilot integration simplifies deployment and makes identity‑driven threat detection more achievable. The product’s Azure Marketplace availability and open XDR approach lower the adoption friction for organizations already embedded in the Microsoft cloud.
That said, buyers should treat vendor claims as starting points for validation. The most defensible path is a well‑scoped pilot: confirm real‑world detection gains, measure analyst productivity improvements, and validate that Copilot‑driven workflows actually shorten incident lifecycles. Properly executed, the combination of OpenText Core Threat Detection and Response with Microsoft telemetry could materially strengthen an organization’s ability to detect sophisticated identity‑centric attacks and reduce costly insider risks; but the benefits will depend on disciplined rollout, governance, and ongoing model stewardship.

---

OpenText’s move underscores a broader market reality: security vendors and platform providers are converging around identity‑and‑behavioral‑first detection models, and Microsoft’s growing AI security stack is shaping how those solutions must operate. For Windows administrators and SOC leaders, the opportunity is real—so long as the rollout is practical, measurable, and governed with the same rigor used for any mission‑critical security investment.

---

Source: Investing.com India OpenText expands threat detection capabilities with Microsoft integrations By Investing.com

 

[ChatGPT]

OpenText’s latest security push tightens its embrace of the Microsoft stack: the company has rolled out OpenText Core Threat Detection and Response, an AI‑driven XDR offering now available on the Azure Marketplace and engineered to ingest Microsoft telemetry from Microsoft Defender for Endpoint, Microsoft Entra ID, and to feed Microsoft’s Security Copilot with richer context. The product — positioned as a component of the OpenText Cybersecurity Cloud and described by the vendor as powered by “hundreds of AI algorithms” and unsupervised machine learning — is pitched at enterprise customers that want deeper behavioral analytics, identity‑aware detection, and faster incident investigation inside Microsoft‑centric environments.

Background​

OpenText’s announcement builds on an industry trend: vendors are moving from siloed endpoint/identity products toward identity‑centric XDR platforms that correlate signals across endpoints, identity systems, cloud workloads and applications. OpenText positions Core Threat Detection and Response as a cloud‑first, composable open XDR solution that leverages Azure for scale and native Microsoft signals for richness, while also offering a “Threat Integration Studio” to ingest telemetry from non‑Microsoft sources. The vendor frames the launch as a countermeasure to both outside attackers and expensive insider incidents, quoting industry research on the cost of insider risk to justify the emphasis on behavioral analytics.
At a practical level the product is being marketed in two complementary ways: (1) as a way to enhance existing Microsoft investments — applying unsupervised ML and behavioral risk scoring on top of Defender and Entra telemetry — and (2) as a broader XDR fabric that can unify third‑party telemetry through the Threat Integration Studio. The solution is currently available as a limited release/early adopter program and listed on the Azure Marketplace to simplify procurement and deployment for Microsoft‑centric customers.

---

What OpenText Is Claiming (Technical Overview)​

Architecture and delivery​

• Cloud‑first delivery on Microsoft Azure; available via the Azure Marketplace which speeds procurement and licensing alignment for organizations already using Azure services.
• Composable open XDR architecture built to integrate with SIEMs, SOARs, endpoint products and identity providers via prebuilt connectors and the Threat Integration Studio.

Data sources and Microsoft integrations​

• Native ingestion and enrichment of telemetry from Microsoft Defender for Endpoint (endpoint signals) and Microsoft Entra ID (identity and sign‑in activity) to fuse endpoint and identity signals into higher‑fidelity detections.
• Designed to feed contextual signals into Microsoft Security Copilot, delivering AI‑generated summaries and guided playbooks to analysts to accelerate triage workflows.

Detection technology​

• Vendor claims the platform uses hundreds of AI algorithms, including unsupervised machine learning, behavioral risk scoring, and anomaly detection, to identify slow‑moving or credential‑based attacks that evade signature or IOC‑driven systems. This is promoted as particularly useful for early‑stage insider threats and account misuse.

Analyst experience​

• Alerts come with natural‑language summaries and mapped MITRE ATT&CK context (OpenText calls this the Cybersecurity Aviator), aimed at reducing alert fatigue and lowering the skill barrier for effective triage.

---

Why This Matters for Microsoft‑centric Enterprises​

• Enhanced telemetry fusion: Combining Defender endpoint telemetry with Entra identity context addresses a longstanding gap: endpoint signals without identity context can miss patterns like credential misuse or lateral movement that look legitimate at the process level. Fusing these signals yields higher‑confidence incidents and fewer noisy alerts.
• Faster investigator workflows: Feeding the enriched signal set into an LLM‑driven assistant (Security Copilot) with human‑readable summaries can shorten mean time to investigate (MTTI) and mean time to respond (MTTR), assuming the summaries and suggested playbooks are accurate and relevant.
• Procurement and deployment simplification: The Azure Marketplace listing lowers friction for cloud procurement teams and aligns OpenText’s telemetry collection with Azure governance and identity models for enterprises that standardize on Microsoft cloud services.

---

Strengths and Practical Benefits​

• Identity‑aware detection — The explicit fusion of Entra ID and Defender signals addresses high‑impact attack classes (credential misuse, privilege escalation, lateral movement, insider abuse) that often cause the most costly breaches.
• Behavioral analytics for subtle attacks — Unsupervised models and behavioral scoring are well suited to spotting anomalies that rules and signatures miss, including slow lateral movement or lateral access patterns that blend with normal activity.
• Reduced alert noise — Risk‑based prioritization and natural‑language summaries promise to reduce SOC toil and allow analysts to focus on high‑impact incidents first. This is an operational ROI lever many customers need given persistent staffing shortages.
• Open ingestion model — By allowing third‑party telemetry via Threat Integration Studio, OpenText avoids being a closed Microsoft‑only silo and supports hybrid stacks where customers retain other investments.

---

Risks, Caveats and What Vendors Don’t Prove (and Why You Should Care)​

• Claims ≠ independent validation: Statements such as “uses hundreds of AI algorithms” and promises to “dramatically enhance detection capability” are vendor descriptions, not empirical performance metrics. These should be treated as marketing until third‑party tests, MITRE evaluations or customer case studies provide independent verification. The product is new and marketed as limited release to select customers.
• Model transparency and explainability: Unsupervised ML and ensemble models can generate detections without easily interpretable rules. While natural‑language summaries help, SOCs must insist on traceability — why was an alert raised, which signals contributed, and what was the confidence level — to avoid blind trust in opaque AI outputs.
• False positives and false negatives: Advanced behavioral models reduce some false positives but can generate new ones if not tuned to organizational context. Conversely, adversaries can craft low‑and‑slow campaigns designed to mimic “normal” behavior. Continuous calibration and local evaluation remain essential.
• Data privacy and residency concerns: Ingesting identity and endpoint telemetry raises questions about what data is stored, who can access it, how long logs are retained and where data is physically located — particularly for regulated sectors and global enterprises. Contracts and data processing addenda must be explicit.
• Vendor and platform coupling: Deep integration with Azure and Microsoft services is an advantage for Azure‑centric shops, but organizations with multi‑cloud or on‑premises constraints should evaluate potential lock‑in or migration complexity. The “open” aspect mitigates this risk, but connectors, data transformation and orchestration still carry integration overhead.
• Security of the supply chain and AI components: Feeding higher‑level signals into a third‑party LLM‑driven assistant (or receiving LLM suggestions) introduces new attack surfaces: model poisoning, prompt injection risks, or misuse of generated remediation actions if not properly sandboxed and vetted.

---

How to Evaluate OpenText Core Threat Detection and Response — A Practical Guide​

When considering this solution alongside Microsoft native services and third‑party XDR vendors, run a structured evaluation:

• Define success metrics (baseline and targets)
• Example KPIs: Reduction in false positive rate, MTTI/MTTR reduction, percent of incidents auto‑prioritized correctly, SOC hours saved per month.
• Start a limited pilot with representative telemetry
• Ingest a realistic subset of Defender + Entra telemetry and any critical third‑party logs.
• Ensure the pilot includes normal business cycles and peak activity windows.
• Measure detection coverage and signal provenance
• For each detection, document which signals contributed, why the model flagged the behavior, and the analyst path to resolution.
• Test adversarial scenarios and edge cases
• Simulate credential misuse, slow lateral movement, and insider data exfiltration in a controlled environment to assess detection fidelity.
• Validate the analyst experience
• Review the Cybersecurity Aviator (natural‑language output) for clarity, accuracy and helpfulness in reducing triage steps.
• Confirm data‑handling and compliance requirements
• Verify data residency, retention, encryption at rest/in transit, and access controls. Update contracts with specific SLAs and DSAs.
• Operational readiness and runbooks
• Ensure SOC playbooks align with the product’s playbook suggestions and validate automated responses within a safe testing environment.
• Cost modeling
• Build TCO models that include ingestion volume pricing, storage, integration engineering effort, and expected SOC efficiency gains.

---

Deployment Checklist (Operational Steps)​

• Inventory current telemetry sources and retention policies.
• Map identity and endpoint correlation needs (which Entra logs, which Defender signals).
• Register for the Azure Marketplace offering and configure tenant permissions for telemetry ingestion.
• Deploy connectors via Threat Integration Studio and validate dataflow end‑to‑end.
• Configure risk thresholds and analyst notification channels (email, SIEM, ticketing).
• Run a two‑week baseline to let unsupervised models learn “normal” behavior (expect a learning period).
• Review initial detections alongside SOC analysts — refine thresholds and suppression rules.
• Implement governance: who can change detection thresholds, who approves automated responses, and how model updates are audited.
• Schedule regular model retraining/validation cadence and operational reviews.

---

Privacy, Compliance and Contract Considerations​

• Data Residency: Ask where telemetry and derived artifacts are stored (Azure region) and request contractual guarantees for data location if subject to local regulations.
• Access Controls: Insist on role‑based access control and immutable audit logging for all admin actions in the security platform.
• Export and Deletion Rights: Ensure you can export historical telemetry and purge data if required for legal or regulatory reasons.
• Intellectual Property (AI): Clarify ownership of derived detection models and whether models trained on your telemetry are proprietary to you, OpenText, or co‑owned.
• Liability and SLAs: Define incident detection/response SLAs and remediation obligations in case of system failures or misdetections that lead to harm.

---

Competitive Context — Where OpenText Fits​

OpenText’s play is not a direct one‑to‑one swap for Microsoft Defender or Entra; it’s an augmentation layer that aims to extract more value from Microsoft telemetry while offering an ingestion path for other vendors. This puts it in competition or partnership territory with other XDR and SIEM vendors that also offer identity‑endpoint fusion and LLM‑assisted workflows.
For security teams already committed to Microsoft security tooling, the Azure Marketplace delivery and native Entra/Defender connectors make OpenText an attractive candidate for incremental value. For multi‑vendor or multi‑cloud shops, the Threat Integration Studio and open architecture are helpful — but integration complexity and validation are the deciding factors.

---

Verdict: Where OpenText Excels — and Where Customers Must Be Cautious​

OpenText brings a strong enterprise pedigree and a pragmatic approach to leveraging Microsoft signals for higher‑confidence detections. The integration with Security Copilot and the Azure Marketplace listing are practical advantages for Microsoft‑centric customers seeking to reduce SOC noise and improve incident triage. The behavioral analytics and identity fusion approach address real gaps that many security teams face today.
However, buyers should treat vendor claims as the start of due diligence, not proof of performance. Independent validation, real‑world pilot tests, regulatory compliance checks and careful contractual protections around data and AI behavior are non‑negotiable. The promise of “hundreds of AI algorithms” and “reduced alert fatigue” will only materialize when a product shows measurable improvements in detection accuracy, investigator efficiency and demonstrable ROI in customer environments.

---

Final recommendations for Windows and Azure administrators​

• Prioritize a pilot that mirrors production: include real Defender and Entra logs, real users and scheduled activity to let the models learn actual behavior patterns.
• Require traceability: insist on incident breakdowns that show contributing signals and confidence levels so human analysts can challenge and verify AI conclusions.
• Build governance: define who approves automated responses, how playbooks are tested, and how AI updates are logged and reviewed.
• Negotiate data protections: enforce clear contractual language on data residency, retention policies and model ownership.
• Monitor metrics continuously: track MTTR, false positive rate and SOC workload before and after deployment to quantify the product’s value.

OpenText’s move to fold deeper Microsoft integration into its Core Threat Detection and Response offering is a meaningful step for enterprises that want identity‑aware, AI‑augmented detection without abandoning Microsoft’s security investments. The technical approach — behavioral risk scoring, unsupervised models, identity+endpoint fusion — aligns with modern detection needs. Yet, as with any AI‑centric security technology, outcomes depend on rigorous validation, careful configuration and vigilant operational governance. For organizations ready to pilot a layered, identity‑centric XDR approach, OpenText’s Azure Marketplace availability and native Microsoft connectors make it a logical candidate — provided the necessary independent testing and contractual safeguards are in place.

---

Conclusion: OpenText has positioned Core Threat Detection and Response as a practical enhancement for Microsoft environments — a platform that promises to convert raw endpoint and identity telemetry into higher‑fidelity, prioritized incidents that accelerate SOC workflows. The product’s success will hinge less on product marketing and more on measurable detection improvements, transparent model behavior, and strong governance around telemetry and AI outputs. Organizations evaluating the offering should insist on evidence — pilot metrics, detection provenance, and contractual protections — before scaling it across critical workloads.

---

Source: Investing.com OpenText expands threat detection capabilities with Microsoft integrations By Investing.com