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

 

[ChatGPT]

OpenText has expanded the availability of its AI-powered security offering, OpenText Core Threat Detection and Response, with deeper, native integrations into the Microsoft security stack — notably Microsoft Defender for Endpoint, Microsoft Entra ID, and Microsoft Security Copilot — and has made the solution more accessible to Microsoft-centric customers through Azure and the Azure Marketplace.

Background​

OpenText first positioned Core Threat Detection and Response as the center of its next-generation OpenText Cybersecurity Cloud earlier in 2025, marketing the product as a cloud-first, composable open XDR platform that leverages unsupervised machine learning and behavioral analytics to detect insider threats, credential misuse, and advanced hands‑on‑keyboard attacks. The vendor emphasized Azure as the primary delivery plane and built pre‑configured integration kits to ingest telemetry from Defender for Endpoint and Entra ID while feeding contextual signals into Security Copilot workflows.
This October update formalizes broader availability and reiterates that the product will be available via the Azure Marketplace, reducing procurement friction for enterprises already standardized on Microsoft cloud tooling. OpenText positions the integration as identity‑centric XDR: fusing endpoint telemetry with identity signals to raise the signal‑to‑noise ratio for SOC teams.

---

What OpenText announced — the essentials​

• The Core message: OpenText Core Threat Detection and Response is now more widely available and deeply integrated with Microsoft Defender for Endpoint, Microsoft Entra ID (identity), and Microsoft Security Copilot (Copilot for Security).
• Delivery model: the solution is cloud‑hosted on Microsoft Azure and offered through the Azure Marketplace, enabling faster deployment and simpler procurement for Azure customers.
• Key capabilities emphasized by OpenText: behavior‑based indicators, identity context fusion, natural‑language summaries, guided investigations, and playbook‑driven automated response — all aimed at cutting alert noise and accelerating mean time to respond (MTTR).

These are vendor announcements and product positioning intended for enterprise security teams that have already invested heavily in Microsoft security telemetry as their primary signal source.

---

Integration deep dive: Defender, Entra ID, and Security Copilot​

Microsoft Defender for Endpoint: endpoint telemetry as the backbone​

OpenText ingests Defender for Endpoint telemetry to capture process events, file behaviors, endpoint alerts, and other host‑level signals. By adding behavioral baselining and unsupervised anomaly detection on top of Defender data, OpenText aims to detect subtle, credential‑based or slow-moving attacks that signature or IOC-based solutions can miss. This approach is common in XDR architectures and is explicitly called out by OpenText as a primary data source.

Microsoft Entra ID: identity context for higher‑fidelity detections​

The platform fuses Entra ID (formerly Azure AD) telemetry — sign‑in events, risked sign‑ins, conditional access signals, and device identity mappings — with endpoint behavior to build identity‑aware incidents. By correlating who did what (identity) with what happened on which machine (endpoint), the system prioritizes incidents that show both behavioral deviation and risky access patterns, which are typical precursors to account takeover and insider data misuse. OpenText explicitly markets the identity fusion as central to catching credential abuse and lateral movement.

Microsoft Security Copilot: augmenting analyst workflows​

OpenText states that it feeds behavior‑based indicators, identity correlation, and incident narratives into Microsoft Security Copilot, which is intended to provide analysts with concise summaries, suggested investigation steps, and recommended containment actions. Microsoft has been expanding Security Copilot’s agentic and partner‑built capabilities, and OpenText’s integration is designed to make Copilot outputs more context‑rich and actionable by pre‑packaging correlated evidence and playbooks for the assistant to consume.

---

The technology claims — what’s verifiable and what to treat cautiously​

OpenText’s public materials make several technical claims that buyers will want to validate during evaluation:

• Claim: the product uses hundreds of AI algorithms and unsupervised machine learning to continuously learn an organization’s “unique normal.” This phrasing appears repeatedly in vendor collateral and press materials. It describes a multi‑model detection stack (anomaly detection, entity scoring, correlation/story engines, and natural language explanation layers), but the exact model architectures, training data, and detection performance metrics are proprietary and not externally audited in the announcement. Treat the “hundreds of algorithms” claim as marketing shorthand for a complex model ensemble rather than a testable performance metric.
• Claim: agentless, fast onboarding with a 30‑day backfill to produce actionable detections within hours. OpenText product pages and blog posts describe SaaS onboarding via native Microsoft APIs and a typical backfill workflow; however, real‑world time‑to‑value depends on tenant size, telemetry volume, API throttles, and customer configuration. The vendor’s stated deployment speed is plausible but should be validated in pilot deployments.
• Claim: reduction of alert noise and higher‑confidence detections when fused with Entra signals. This is logically compelling (identity context often reduces false positives) and consistent with industry practice, but the magnitude of alert reduction will vary widely by customer and must be measured in controlled pilots. OpenText cites customer interest in insider threat and credential misuse cases; independent validation is required to quantify real gains.

In short: the high‑level technical claims are consistent with modern XDR patterns and are corroborated across OpenText announcements and product pages, but many operational and performance statements are vendor‑centric and should be piloted for verification.

---

Independent corroboration and marketplace availability​

Multiple independent sources corroborate key elements of the announcement:

• OpenText’s corporate press release and investor/PR channels describe the Microsoft integrations and product availability.
• The OpenText product page and blog confirm the technical design (behavioral analytics, unsupervised ML, identity fusion) and the Azure delivery model.
• Microsoft’s Security blog and the broader Security Copilot roadmap show that Microsoft has been enabling partner agents and integrations to enrich Copilot workflows — a context that makes OpenText’s integration both feasible and strategically aligned.
• The Azure Marketplace and Microsoft community listings highlight the platform’s availability on the Marketplace, simplifying procurement and governance for enterprises on Azure.

Taken together, these sources support the headline claims: the offering exists, it is aimed at Microsoft‑centric enterprises, it is available via Azure channels, and it targets identity‑centric detection scenarios.

---

Why this matters for Microsoft‑centric enterprises​

• Identity‑centric detection addresses one of today’s highest‑value threat classes: credential compromise and insider risk. By correlating Entra sign‑ins and device identity with endpoint behaviors, analysts can triangulate higher‑confidence incidents that would otherwise be lost in alerts from multiple siloed tools.
• Plug‑and‑play Azure delivery and Azure Marketplace listing reduce procurement cycles and align technical controls with existing cloud governance, data residency, and network architecture. For organizations that already centralize telemetry with Microsoft tools, an integrated XDR that speaks native APIs removes a major integration burden.
• Feeding pre‑correlated evidence into Microsoft Security Copilot can shorten analysis lifecycles if Copilot’s recommendations are accurate and contextually complete. In quality deployments, Copilot augmentation can reduce manual evidence collection and accelerate containment actions. However, a Copilot‑driven workflow also raises new governance needs (see Risks section).

---

Risks, limitations, and operational cautions​

No single vendor product eliminates the need for disciplined security governance. Consider these critical risk areas before broad adoption:

• Model explainability and investigation integrity: AI‑driven detections depend on model inputs and configuration. SOC teams must have transparent incident narratives, clear evidence trails, and the ability to export raw telemetry for independent verification. Relying only on summarized reasoning (LLM outputs) without traceable artifacts risks missed context and auditability gaps.
• False positives and false negatives: vendor claims of “reduced alert noise” are plausible but variable. Over‑trusting statistical prioritization without baseline validation can create dangerous blind spots. Pilot programs should measure true positive rates, false positive rates, and detection latency for representative threat scenarios.
• Data residency, compliance, and telemetry routing: routing sensitive Entra or Defender telemetry into a third‑party cloud service introduces regulatory and compliance questions (GDPR, HIPAA, sectoral rules). Customers must confirm contractual data residency, encryption‑in‑transit and at‑rest, log retention policies, and Microsoft‑to‑vendor data flows before enabling ingestion.
• Copilot risks: Security Copilot is powerful but can hallucinate or produce recommendations that require human oversight. When Copilot actions are tied to playbooks that can trigger automated responses, strict guardrails, approvals, and rollback procedures are essential to avoid unintended disruptions.
• Vendor lock‑in and integration scope: OpenText’s Threat Integration Studio promotes multi‑vendor ingestion, but deep value is strongest when Defender and Entra are primary telemetry sources. Organizations should evaluate how the platform coexists with existing SIEM/SOAR investments and whether integration costs offset projected ROI.
• Claims without independent benchmarks: statements like “hundreds of AI algorithms” and “actionable detections in hours” are marketing language unless validated by independent testing or customer case studies. Treat such claims as starting points for technical validation rather than guarantees.

---

Practical rollout recommendations — a pilot checklist​

A disciplined pilot is the best way to validate OpenText Core Threat Detection and Response in your environment. Follow these sequential steps:

• Scope and objectives: define clear pilot objectives (e.g., reduce false positives by X%, detect simulated credential abuse within Y minutes, integrate with an existing incident response playbook).
• Data mapping: identify required Defender for Endpoint and Entra ID tenants, necessary API permissions, data residency constraints, and legal approvals for telemetry sharing.
• Baseline measurement: capture current SOC metrics (alerts per day, average MTTI, false positive rate) to compare pilot outcomes.
• Controlled ingest: enable ingestion for a limited set of tenants or organizational units and backfill the agreed historical window; collect model outputs and raw evidence.
• Validate detections: run a red team or scripted scenarios (credential theft, lateral movement, exfil simulation) and measure detection time and quality.
• Copilot evaluation: run analyst‑assisted playbooks in a review mode before allowing automated actions; evaluate recommended actions for accuracy and suitability.
• Governance and rollback: confirm playbook approvals, operational SLAs, and a rollback plan for any automated responses.
• Measure and iterate: compare pilot metrics against baseline, document gaps, and iterate on connector tuning, playbooks, and analyst workflows.

This pilot sequence protects operations while producing measurable evidence of value.

---

Governance, model stewardship, and SOC readiness​

To realize the most value, organizations should pair technical pilots with governance and operational controls:

• Model stewardship: schedule regular model reviews, monitor concept drift, and maintain a test set of labeled incidents to detect degradation.
• Explainability: require the vendor provide incident timelines, event IDs, and raw telemetry export for every prioritized detection.
• Human‑in‑the‑loop controls: ensure Copilot recommendations are advisory by default and require human approval for high‑impact automated playbooks.
• Logging and audit trails: preserve immutable records of model outputs, analyst decisions, and automated responses for incident reviews and compliance audits.
• Cross‑tool choreography: map OpenText playbooks to existing SOAR runbooks and update service‑level agreements (SLAs) and escalation matrices accordingly.

---

Pricing, availability, and procurement notes​

OpenText states Core Threat Detection and Response is available now as part of the OpenText Cybersecurity Cloud and has been listed on the Azure Marketplace to streamline procurement for Azure customers; earlier releases ran as limited or early access programs and the company is expanding availability. Pricing models for XDR services typically include subscription tiers, data ingestion volumes, and optional professional services for onboarding — all items that must be negotiated and validated during procurement. Expect enterprise licensing conversations to cover telemetry volume, retention, support SLAs, and professional services for pilot and deployment.

---

Bottom line — who should care, and why​

For organizations that have standardized on Microsoft Defender for Endpoint and Microsoft Entra ID, OpenText Core Threat Detection and Response offers a pragmatic path to add behavioral analytics, identity‑aware correlation, and AI‑assisted analyst workflows without rebuilding telemetry pipelines. The native Azure delivery and Marketplace listing simplify procurement and governance for Microsoft‑centric enterprises, while prebuilt connector kits lower integration effort.
However, the value will be realized only through careful pilots, measurable validation of detection efficacy, and robust governance around AI‑augmented workflows. Vendor marketing claims around the number of algorithms and alert reduction require independent verification in production‑like conditions; security leaders should insist on measurable outcomes (true positive rate, false positive reduction, MTTI/MTTR improvements) before scaling.

---

Final recommendations for security leaders​

• Treat this as an opportunity to modernize identity‑aware detection, not as a plug‑and‑play cure for all SOC problems.
• Run a scoped pilot with defined success metrics and real adversary emulation scenarios.
• Insist on explainable detections and ready access to raw telemetry for audits and investigations.
• Establish strict guardrails for Copilot‑driven automation; begin in advisory mode.
• Negotiate contractual protections for data residency, access controls, and model governance.

OpenText’s announcement is a notable example of the market trend toward identity‑centric, AI‑assisted XDR on Azure. The technical direction — fusing Defender endpoint telemetry with Entra identity signals and augmenting analyst workflows via Security Copilot — is compelling for Microsoft‑centric environments, but the leap from product claims to SOC value will depend on rigorous validation, governance, and ongoing oversight.

---

Source: The Globe and Mail OpenText Expands Availability of Core Threat Detection and Response with Deep Microsoft Integrations

 

[ChatGPT]

OpenText’s latest expansion of Core Threat Detection and Response signals a deliberate push to marry AI-driven XDR capabilities with Microsoft's security ecosystem, delivering tighter identity-to-endpoint correlation and streamlined investigator workflows that aim to reduce alert fatigue while accelerating time-to-containment.

Background​

OpenText has repositioned its cybersecurity product set around the OpenText Cybersecurity Cloud and, as part of that strategy, is promoting OpenText Core Threat Detection and Response as a central AI-powered XDR offering. The product is presented as deeply integrated with Microsoft security telemetry and services—specifically Microsoft Defender for Endpoint, Microsoft Entra ID, and Microsoft Security Copilot—to provide identity-aware detections, behavior-based indicators, and guided investigation playbooks.
The vendor describes the offering as available now across the OpenText Cybersecurity Cloud, with earlier messaging that tied general availability to its Cloud Editions (25.2). OpenText positions the integration as both a technical and commercial bridge: technical, because it ingests and correlates Microsoft endpoint and identity signals; commercial, because many enterprise customers already standardize on Microsoft security tooling and seek ways to extend detection and response without replacing the Microsoft stack.
OpenText also highlights results of third-party research showing complexity and unstructured data are major barriers to improved security outcomes—a framing used to promote the value of AI-driven correlation and simplified SOC workflows.

---

Overview: what OpenText says it delivers​

OpenText frames Core Threat Detection and Response as an AI-first XDR layer that adds behavior and identity context on top of endpoint telemetry to:

• Improve detection of insider threats and data misuse by spotting anomalous access and exfiltration patterns.
• Surface early signals of account takeover and identity attacks by correlating risky sign-ins with device signals.
• Detect early-stage ransomware behaviors and hands-on-keyboard activity before full encryption or impact.
• Reduce alert noise via behavior-based indicators and confidence scoring, enabling triage prioritization.
• Enrich cases for guided investigations and drive automated containment via playbooks.

The message emphasizes speed and accuracy: summarization and recommended actions aim to help analysts move from signal to response with “higher confidence.” OpenText states the product extends Microsoft Security Copilot capabilities with additional behavioral and identity context derived from continuous analytics.

---

Why the Microsoft integrations matter​

Identity + endpoint = higher fidelity detection​

Correlation between identity and endpoint telemetry is not new, but it is increasingly critical. Threats today use stolen credentials, lateral movement, and legitimate admin tools to fly under signature-based defenses. By combining Entra ID identity events (sign-in risk, Conditional Access signals, token anomalies) with endpoint telemetry from Defender for Endpoint, a detection engine can:

• Distinguish legitimate admin activity from unauthorized use of privileged credentials.
• Detect anomalies where a credential authenticates from an unusual device or geolocation then performs sensitive actions.
• Link signs of credential compromise (e.g., atypical risky sign-ins) with subsequent endpoint reconnaissance or persistence techniques.

This identity-centric posture aligns with modern Zero Trust patterns that place identity at the core of access decisions and threat prioritization.

Extending Microsoft Security Copilot for Security​

Microsoft Security Copilot provides analysts with AI-assisted summaries, natural-language investigation workflows, and recommendations. OpenText’s offering claims to feed behavior-based indicators and richer identity context into Copilot-driven workflows, theoretically improving the quality of Copilot outputs and suggested remediation actions. This makes sense: better context produces more actionable AI summaries.

Operational synergy for Microsoft-centric organizations​

Many enterprises are heavily invested in Microsoft 365, Azure, and Defender stacks. A solution that leverages those investments—rather than displacing them—can reduce integration overhead for security teams, lower time-to-value, and preserve existing identity and endpoint telemetry retention and governance models.

---

Technical and product strengths​

• Identity-aware correlation: The combination of Entra ID signals with endpoint telemetry addresses detection gaps where identity is the primary attack vector. Prioritizing identity-linked anomalies can meaningfully reduce wasted investigations.
• Behavior-based indicators: Moving beyond static IOC matching to behavior profiling and anomaly detection can surface novel attacks and early-stage activity that signatures miss.
• AI-assisted triage and guided investigations: Automating case enrichment and surfacing recommended playbooks reduces mean time to acknowledge (MTTA) and mean time to remediate (MTTR) for routine workflows.
• Alert noise reduction: Vendor messaging centers on prioritization—fewer low-value alerts passed to analysts means SOC resources are focused on high-confidence incidents.
• Composable XDR approach: OpenText promotes an open integration architecture—ingesting telemetry beyond Microsoft (via a Threat Integration Studio)—which supports heterogeneous estates.
• Cloud-native deployment on Azure: For customers already in Azure, hosting reduces latency between telemetry sources and analytics, and simplifies data residency alignment for many regions.

---

What’s new vs. previous OpenText messaging​

OpenText initially positioned Core Threat Detection and Response as part of its Cloud Editions release cadence earlier in the year. The new messaging emphasizes deeper Microsoft integrations and explicit support for Microsoft Security Copilot—the commercial pivot is toward seamless co-existence with the dominant endpoint and identity vendors in many enterprises. This is less about replacing existing tools and more about enhancing them with additional AI-driven correlation and behavioral analytics.

---

Critical analysis — where the claims hold, and where caution is warranted​

Credible strengths​

• Integrating identity and endpoint telemetry is a sensible and well-proven architectural approach to raise detection fidelity. Enterprises that have already standardized on Defender and Entra ID will see real operational benefits from a product that reduces friction in ingesting those signals.
• AI-driven case enrichment and guided playbooks are practical usability improvements that reduce cognitive load on analysts—especially important in understaffed SOCs.
• Reducing alert noise is a high-value promise for security teams drowning in low-confidence alerts. If behavior-based indicators and confidence scoring are implemented well, they can deliver measurable efficiency wins.

Claims that warrant skepticism or verification​

• Statements such as “uses hundreds of AI algorithms” and promises of dramatic alert reduction are business and marketing claims that are difficult to independently verify without testing. These should be treated as vendor claims until validated in customer pilots.
• Any assertion that AI will eliminate false positives or comprehensively surface “often unnoticed” attacks is optimistic. AI can reduce noise, but it also introduces new failure modes (drift, adversarial manipulation, model blind spots).
• Deep integrations with Microsoft telemetry imply significant data sharing and routing. The security, privacy, and compliance implications of moving identity and endpoint telemetry into a third-party analytics environment require careful review—particularly for regulated industries.

---

Operational and security risks to consider​

Data residency, privacy, and telemetry governance​

Forwarding Entra ID and Defender telemetry to a third-party cloud requires explicit governance. Organizations must review:

• Where telemetry is stored and processed (which cloud regions).
• Retention policies and deletion controls for sensitive authentication logs.
• How identity metadata and device fingerprints are protected in transit and at rest.
• Compliance with industry regulations (e.g., GDPR, HIPAA, sector-specific rules).

Vendor trust and supply-chain concerns​

Delegating detection logic and enriched analytics to an external vendor increases reliance on that vendor's security posture. SOCs should require security reviews, third-party attestations, and transparency around how detection models are trained and updated.

Overreliance on AI and automation​

Automation and AI-driven playbooks accelerate response but can lead to:

• Over-triggered containment actions if confidence thresholds are misconfigured.
• Alert desensitization to novel attack patterns not represented in training data.
• Dependence on vendor-supplied playbooks, reducing internal forensic maturity.

Integration complexity and costs​

Even with advertised “deep integrations,” enterprises may encounter:

• Additional licensing or connector fees for ingesting full telemetry sets.
• Network egress costs when routing logs to a cloud analytics platform.
• Increased operational complexity when orchestrating response actions between Microsoft services and OpenText playbooks.

Single-vendor consolidation trade-offs​

While consolidating to a single XDR layer simplifies management, it may also:

• Create vendor lock-in risks and decrease flexibility to swap components.
• Reduce diversity of detection methodologies if the consolidated stack shares common blind spots.

---

Practical guidance for evaluation and deployment​

1. Baseline telemetry and use-case mapping​

• Enumerate the identity and endpoint telemetry currently available from Entra ID and Defender for Endpoint.
• Map the critical use cases you need: insider threat detection, account takeover detection, early ransomware indicators, and triage reduction.
• Define acceptance criteria: detection accuracy, false-positive rate, MTTR reduction targets, and required retention windows.

2. Pilot with realistic data and red-team scenarios​

• Run a time-boxed pilot that ingests production telemetry or realistic synthetic workloads.
• Include red-team/blue-team exercises that simulate credential theft, lateral movement, and hands-on-keyboard ransomware staging.
• Measure the solution against your acceptance criteria, focusing on signal-to-noise ratio and investigator time saved.

3. Validate governance and compliance​

• Obtain documentation about where telemetry is processed and stored (regions and data centers).
• Confirm contractual SLAs for data handling, breach notification, and compliance certifications (SOC 2, ISO 27001, etc.).
• Clarify controls for data deletion and the ability to restrict telemetry movement to meet regulatory requirements.

4. Tune detection thresholds and playbooks​

• Start with conservative automated responses; require analyst approval for high-impact containment.
• Iterate thresholds based on pilot feedback and false-positive analysis.
• Maintain a catalog of playbooks and ensure they follow internal incident handling and legal requirements.

5. Monitor model drift and performance​

• Establish KPIs to track model performance over time: detection precision, recall, and analyst override rates.
• Schedule model review cycles and require vendor transparency on retraining and data sources.
• Insist upon explainability mechanisms that allow analysts to understand why a detection was raised.

---

Architectural considerations​

• Prefer deployments where telemetry stays within your cloud tenancy or region when regulatory constraints demand it.
• Use role-based access controls and least privilege to limit who can view identity-linked enrichment data.
• Integrate with existing SIEM/SOAR workflows to preserve audit trails and forensic readiness.
• Ensure the platform supports multi-cloud and on-prem data sources if you operate a heterogeneous environment.

---

Business and ROI perspective​

OpenText markets Core Threat Detection and Response as a way to amplify existing Microsoft investments, reduce analyst workload, and cut the cost of breaches through earlier detection. From a procurement and ROI lens, buyers should:

• Calculate analyst time saved from reduced triage and prioritize cases.
• Estimate potential cost avoidance for detected early-stage ransomware or prevented exfiltration.
• Factor in licensing, data egress, and integration costs against the expected efficiency gains.

Do not assume instantaneous ROI—real gains typically emerge after tuning, playbook optimization, and analyst adoption.

---

What to ask the vendor before purchasing​

• Can you provide documented, quantitative performance metrics from independent customer pilots or third-party evaluations (false positive/negative rates, MTTR improvements)?
• Exactly which Microsoft telemetry items are ingested, how are they stored, and in which regions?
• What certifications and penetration testing results support platform security and operational resilience?
• How are AI models trained, how often are they retrained, and what safeguards prevent model drift or poisoning?
• What are the costs associated with data ingestion, retention, and additional connectors beyond Microsoft sources?

---

Where this fits in a modern security stack​

OpenText’s approach reflects a broader market trend: vendors are packaging XDR capabilities that layer on existing endpoint and identity tooling—particularly Microsoft’s—so security teams can extract more value from the telemetry they already generate. For organizations with significant Microsoft footprints, these kinds of integrations can accelerate detection maturity without wholesale platform replacement.
However, the right architecture remains context-dependent. Organizations with multi-cloud workloads, strict data residency needs, or bespoke detection logic should evaluate how composable and transparent the vendor’s XDR architecture truly is before consolidation.

---

Final assessment​

OpenText Core Threat Detection and Response offers a pragmatic proposition: combine behavioral analytics with Microsoft identity and endpoint telemetry to reduce alert noise, improve detection fidelity for identity-driven attacks, and accelerate analyst response with AI-driven guidance. For Microsoft-centric enterprises, these integrations are compelling and can produce tangible operational benefits.
That said, many of the most impactful claims—dramatic reductions in noise, hundreds of AI algorithms, and “often unnoticed” attack detection—are vendor assertions that require validation through pilots and independent testing. The move toward deeper integrations increases the need for due diligence around telemetry governance, vendor security posture, model transparency, and long-term operational costs.
Security teams evaluating this solution should prioritize real-world pilots, insist on documentation of data-handling practices, and plan for stepwise automation—beginning with enrichment and guided investigation before enabling fully automated containment. With careful governance and iterative deployment, the offering can be a powerful amplifier of Microsoft-centered security telemetry; without that rigor, organizations risk trading one form of complexity for another.

---

In short, OpenText’s expanded availability of Core Threat Detection and Response with deep Microsoft integrations is a meaningful entry in the AI-driven XDR market. It aligns strongly with identity-first security objectives and answers a clear need to reduce SOC overload. The ultimate value will be determined by real-world accuracy, clarity on telemetry governance, and how well organizations integrate AI-assisted workflows into their existing detection-and-response playbooks.

---

Source: NewswireToday OpenText Expands Availability of Core Threat Detection and Response with Deep Microsoft Integrations - IT Security / Anti-Spam / Cybersecurity - Actuate Corporation | OpenText™ | NewswireToday