Extended detection, investigation and coordinated response
Subscription-led XDR tier and related onboarding
Teams connecting endpoint, network, cloud and security operations
Endpoint count, tier, term, services, integrations and region
A direct answer for buyers
FortiXDR is Fortinet’s extended detection and response capability for correlating security information from multiple parts of an environment, investigating suspicious activity and coordinating remediation through supported security controls. Organisations should consider it when endpoint-only visibility is not enough and the security team needs a more connected workflow across Fortinet Security Fabric components, supported cloud sources and selected third-party technologies. Before proceeding, confirm the endpoint estate, current FortiEDR or FortiEndpoint position, required XDR subscription, data sources, integration methods, response permissions, managed-service expectations and onboarding requirements. Do not assume that every integration, deployment model or response action is automatically included in every license or configuration.
What FortiXDR does
FortiXDR extends detection beyond a single endpoint console. Fortinet describes the platform as correlating security and audit information feeds, including information made available through data lakes, so related activity can be grouped into incidents and evaluated through analytics and automated investigation. The platform can then drive predefined response actions across supported controls.
That operating model matters when an attack moves between identities, endpoints, network paths, email, cloud services or other security layers. Instead of requiring an analyst to manually assemble every clue from separate consoles, an XDR workflow is intended to create more context around an incident and provide a governed path from detection to action.
Who should consider it
FortiXDR is most relevant to organisations with a meaningful security-operations requirement: internal security teams, IT teams carrying security responsibility, distributed businesses, organisations operating mixed cloud and on-premises workloads, and environments that already rely on Fortinet controls and want stronger cross-product coordination.
It is not automatically the right starting point for every company. A small environment that only needs endpoint prevention may be better served by a simpler endpoint package. A mature SOC with complex multivendor analytics may need to position XDR alongside SIEM, SOAR, NDR or existing case-management processes. FourTeck can help map the role before licensing decisions are made.
Security problems the platform is intended to address
Disconnected alerts
A suspicious endpoint event may be more meaningful when it can be related to network, identity, cloud or email activity. FortiXDR is designed to correlate information so the analyst can work with incident context rather than isolated warning messages.
Manual investigation load
Fortinet uses analytics, deep-learning investigation and supporting microservices to automate portions of incident enrichment and analysis. The practical objective is to reserve analyst time for decisions that genuinely need human judgment.
Slow cross-tool response
When response requires changes in several consoles, containment can become procedural and inconsistent. Supported Fortinet and API-based integrations can allow predefined response flows to trigger actions across more than one control.
Unclear automation boundaries
Automation is useful only when authority is well defined. FortiXDR lets buyers plan responses by incident type, severity, scope, users or groups, but each organisation still needs governance, testing and rollback expectations before enabling high-impact actions.
Core capabilities in the XDR operating model
Correlation of security activity across connected sources.
Analytics, enrichment, file analysis, reputation and behavioural context.
Predefined remediation across supported products and connectors.
Native relationships with multiple Fortinet security controls.
Current XDR guidance includes AWS GuardDuty and Google Security Command Center extended detection.
Product-fit matrix
| Requirement | Suitable when | Confirm before ordering |
|---|---|---|
| Cross-domain incident context | Security events need correlation across more than the endpoint layer. | Which Security Fabric, cloud and third-party sources will actually be connected. |
| Automated response | The organisation can define approved actions for selected incident classes. | Approval thresholds, exclusions, business-critical systems and rollback procedures. |
| Fortinet-centred security stack | FortiGate, FortiAnalyzer, FortiSIEM, FortiNAC, FortiMail or related technologies already form part of operations. | Supported versions, connectors, entitlements and required configuration. |
| Cloud detection context | AWS GuardDuty or Google Security Command Center events are relevant to incident detection. | Cloud-account permissions, data access, connector design and current Fortinet support. |
| Managed operations | The buyer needs external monitoring or managed triage rather than only a self-managed platform. | Managed XDR or MDR service scope, deployment compatibility, escalation and commercial terms. |
Verified product and ordering information
FortiXDR is a software and subscription-led security capability rather than a hardware appliance with ports, throughput or rack dimensions. The information below therefore focuses on platform role, licensing and integration points that matter to procurement. Current vendor ordering guidance should always be checked at the time of quotation because SKUs, terms and service requirements can change.
| Brand | Fortinet |
|---|---|
| Product | FortiXDR Extended Detection and Response |
| Product type | Extended Detection and Response security platform / subscription capability |
| Portfolio relationship | Part of Fortinet security operations; current ordering guidance presents XDR as the Discover, Protect and Respond with XDR tier built around the FortiEDR platform. |
| Main function | Correlate security telemetry, investigate incidents and coordinate supported response actions. |
| Current XDR deployment guidance | Cloud deployment is listed for the XDR tier in Fortinet’s 2026 FortiEDR ordering matrix. Do not assume on-premises or air-gapped XDR support without confirming the exact architecture and current vendor entitlement. |
| Current sample XDR bundle sizes | 25, 500, 2,000 and 10,000 endpoint sample bundle references are shown in the 2026 ordering guide. Actual ordering rules and quantities should be validated for the specific quote. |
| Extended detection sources called out in current ordering guidance | Fortinet Security Fabric, AWS GuardDuty and Google Security Command Center. |
| Fortinet integration examples | FortiGate, FortiNAC, FortiSandbox, FortiEMS, FortiSIEM, FortiAnalyzer, FortiRecon, FortiMail and FortiGuard Labs are documented examples. Exact capability depends on version, configuration and entitlement. |
| Third-party integration | API-supporting products and connector categories can include firewalls, identity services, ticketing systems, CASB, cloud workload protection, network sandboxing, data lakes and ZTNA technologies. Confirm each required connector. |
| Managed service | Managed XDR is a separate ordering option. Do not treat managed monitoring as automatically included with a standard XDR subscription. |
| New deployment onboarding | Fortinet’s 2026 ordering guide states that FortiCare Best Practice Service is mandatory for new deployments that include EDR or XDR functionality. Confirm the correct size-based onboarding item. |
| Availability and price | Quotation required. UAE price and availability depend on subscription size, term, services, region, quantity and current vendor policy. |
Licensing, compatibility and scope dependencies
FortiXDR should be purchased as an architecture decision, not as a generic license line. The current Fortinet ordering structure connects the XDR tier to FortiEDR subscription bundles, while managed XDR is presented separately. The exact commercial package can also include onboarding services and may need additional professional services, storage, training or related platform licenses depending on the deployment.
Compatibility also depends on what the buyer expects XDR to see and control. A FortiGate integration that blocks an address, a FortiNAC workflow that isolates a device, a FortiMail action that blocks malicious email, or a cloud connector that supplies security events each has different permissions, version dependencies and operational consequences. FourTeck can help document these dependencies before the bill of materials is finalised.
A practical deployment and purchase journey
Define the security outcome
Decide whether the immediate need is broader detection, faster investigation, automated containment, cloud correlation, endpoint consolidation or a managed operating model. This prevents a feature list from becoming the design brief.
Map telemetry and controls
List endpoint platforms, Fortinet controls, SIEM or data-lake systems, AWS or Google security sources, identity services, email security, ticketing and other tools expected to participate in detection or response.
Build the correct license scope
Confirm endpoint quantity, subscription term, XDR versus managed XDR, onboarding service, support entitlement and any additional services. Current ordering guidance should be used rather than an old renewal or reseller part number.
Design response governance
Categorise response actions into automatic, analyst-approved and manual-only groups. Business-critical systems, service accounts, OT assets and executive endpoints may require different treatment from standard user devices.
Configure and validate
Connect the initial data sources, test detection flow, validate permissions, exercise selected response actions and confirm that escalation paths are understood. A phased rollout is often easier to govern than enabling every possible integration at once.
Operate, tune and review
Security operations should revisit integrations, exclusions, automated actions, endpoint coverage and managed-service boundaries as the environment changes. Renewal planning should use actual operational requirements rather than simply repeat the original bill of materials.
Correlating activity without turning every tool into another silo
One of the strongest reasons to evaluate XDR is the need to relate events that would otherwise live in separate products. FortiXDR is documented as analysing security information feeds across the Security Fabric and other supported sources, then grouping related evidence into incidents. For a security team, the value is not simply that more data is collected. The useful change is that endpoint behaviour, network activity, cloud events and other security context can contribute to one investigation story when the necessary connectors and permissions are present.
This is particularly relevant for attack patterns that rarely stay within a single control boundary. Lateral movement may begin with a compromised credential, touch an endpoint, create unusual network connections and finally involve a cloud workload. A phishing event may be observed first through email, then become meaningful when endpoint execution or suspicious outbound traffic appears. Fortinet documents detection examples including scanning, brute-force activity, command-and-control behaviour, data exfiltration, lateral movement, compromised credentials and potential phishing. Those examples should be treated as categories of analytic coverage, not as a guarantee that every attack will be identified.
During design, buyers should ask which data sources provide high-value context and which merely add noise or cost. Connecting everything is not always the best first step. A phased design that begins with the endpoint layer and the controls most likely to change incident decisions can make validation easier, reduce integration risk and give the security team a clearer baseline for future expansion.
Automated investigation should strengthen analyst judgment, not bypass it
FortiXDR uses a deep-learning engine and investigation services to enrich and evaluate suspicious activity. Documented investigation functions include pulling telemetry and threat intelligence, static and dynamic file analysis, reputation checks, behavioural baselines and other enrichment services. This can shorten the repetitive part of triage, especially when the alternative is manually switching between several consoles and rebuilding context for each alert.
The buying question is how much of that workflow matches the organisation’s existing incident process. A mature SOC may already have case management, threat-intelligence sources, SIEM correlation and formal escalation stages. In that situation, FortiXDR should be mapped into the operating model rather than placed beside it without ownership rules. A smaller security team may value the guided and automated investigation more heavily because it can reduce the number of manual steps required before a response decision.
Either way, teams should define how an XDR incident is opened, who validates high-impact classifications, where case evidence is retained, when another platform remains the system of record and how analysts document exceptions. These operational details often determine whether an XDR deployment genuinely simplifies work or simply adds another interface.
Coordinated response needs policy, testing and business context
FortiXDR supports predefined response logic based on factors such as incident type, severity, scope, users and groups. Documented response examples include device isolation, credential-related actions, threat-intelligence updates and instructions to connected controls. Fortinet also documents examples in which FortiGate can block an address, FortiNAC can isolate a device and FortiMail can block malicious email. These are useful capabilities when they are configured for the exact environment and the organisation has authorised the action.
Automation should not be treated as an all-or-nothing setting. A low-risk action such as opening a ticket or adding context may be appropriate for broad automation. Isolating a production server, expiring a privileged credential or blocking a shared service can have a much larger operational effect. Buyers should therefore create response classes and test them against real application dependencies before moving from advisory workflows to automatic enforcement.
This is also where IT and security teams need joint ownership. The SOC may recognise the threat pattern, while infrastructure, application and business teams understand which systems have fragile dependencies. FourTeck can assist with planning and configuration scope, but the customer should provide business-critical system lists, escalation contacts and approved response boundaries so the technical configuration reflects the actual organisation.
Ideal business environments and use cases
Fortinet-centred enterprise security
Organisations using FortiGate and other Security Fabric components can evaluate XDR as a way to connect detection and response activity across technologies already present in the environment.
Hybrid user and workload estates
Distributed endpoints, servers, mobile devices and cloud workloads can create fragmented investigation paths. The design should confirm current platform support and decide which assets require response authority.
Cloud security operations
The current XDR tier includes extended detection references for AWS GuardDuty and Google Security Command Center, making cloud-event correlation a relevant planning area for organisations using those services.
Teams managing alert pressure
Where analysts spend excessive time collecting context from separate tools, automated enrichment and incident correlation may help streamline the workflow, provided integrations are correctly designed.
IT and OT convergence
Fortinet positions XDR for environments that can include legacy and operational technology considerations. Buyers should be especially cautious about automated isolation and compatibility where production processes are sensitive to interruption.
Managed detection requirements
Organisations without enough in-house monitoring capacity can compare standard XDR with managed XDR or related Fortinet managed services. Service scope must be priced and documented separately.
Integration and operational considerations
An XDR project becomes more predictable when the integration map is prepared before licensing and configuration. Start by identifying the systems that produce security context, the systems that will receive incidents or tickets, and the systems on which response actions may be executed. These three roles are not always the same. A SIEM may remain the main event repository, a ticketing platform may remain the formal workflow system and FortiXDR may provide the cross-product investigation and response layer.
For Fortinet integrations, verify product versions, administrative permissions, network reachability, API access and any required connector settings. For third-party systems, confirm that the connector supports the specific action expected; the existence of an API does not automatically mean every remediation function is available. Cloud integrations also need the right account roles and security boundaries. Security teams should document which credentials or service accounts are used and how those credentials will be rotated.
Operational ownership is equally important. Decide who handles tuning, who approves new automated actions, how exclusions are reviewed, how false positives are investigated and who owns the response when a connected system is unavailable. These choices should appear in the deployment plan and, where relevant, in the requested service scope. FourTeck can help translate the integration map into configuration tasks and quotation items.
Questions to resolve before an order is placed
Procurement checklist for FortiXDR
How FourTeck can assist with planning and quotation
FourTeck can help convert a broad XDR requirement into a clearer purchasing scope. The process can begin with an inventory of endpoints, existing Fortinet products, cloud security sources, SIEM or data-lake platforms, ticketing systems and the controls that may be used for response. From there, the requirement can be separated into subscription items, onboarding, integration work, configuration tasks and any optional professional or managed services.
For buyers who are still comparing approaches, FourTeck can also help distinguish between endpoint-only protection, EDR, XDR and managed operations so that the request is not over-scoped or under-scoped. If the organisation is already invested in Fortinet, the review can focus on how the existing Security Fabric may contribute telemetry and response. If the environment is multivendor, the review should identify the specific third-party connectors required rather than assuming universal integration.
You can review related FourTeck technology products, discuss configuration and implementation services, or use the FourTeck contact page to share the endpoint count, subscription requirement and desired project scope.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for FortiXDR subscriptions, onboarding items and any related Fortinet components required for the proposed architecture. Availability may depend on subscription tier, endpoint quantity, contract term, license region, new-customer status and current vendor lead time. A quote should identify which items are subscriptions, which are services and which are optional so procurement teams can compare proposals accurately.
Installation and configuration are also scope-dependent. Endpoint onboarding, connector setup, Security Fabric integration, cloud-source configuration, response-playbook design, testing, documentation and knowledge transfer may represent separate work packages. Buyers who need these activities should request them explicitly rather than assuming they are included in the product subscription.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
For organisations operating across Dubai, Abu Dhabi, Sharjah and Ajman, FourTeck can coordinate requirement review, quotation preparation and project planning through one discussion. Multi-site buyers should provide the endpoint quantity by location, any separate business units or tenants, the cloud and data-centre architecture, local security responsibilities, and whether configuration or installation assistance is needed at each site. This is particularly useful when response policies differ between headquarters, branch users, server environments or operational locations. Delivery, subscription activation, service scheduling and project timing should be confirmed after the exact requirement and destination details are known.
GCC Availability
Organisations planning FortiXDR across the GCC can use FourTeck to coordinate requirement review, license selection, quotation planning and project scope for regional deployments. A multi-country XDR project should begin with more than a total endpoint count. The buyer should identify the destination country for each subscription, the user and workload population, the existing Fortinet estate, required cloud integrations, any third-party connectors and whether managed operations are being considered. Requirements can vary between the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain and Oman, particularly where the customer has different subsidiaries, cloud accounts or operational responsibilities.
Product availability, licensing rules, delivery schedules for any related physical components, service visits, project scope and vendor lead times can vary by country, model, quantity and requirement. Share the destination, subscription tier, endpoint quantity, preferred term, deployment location and expected timeline with FourTeck before finalising procurement. No assumption should be made about local stock, fixed implementation dates or country-specific entitlement until the quotation and project scope have been confirmed.
Africa Availability
For organisations evaluating FortiXDR for African operations, FourTeck can assist with product selection, subscription planning, endpoint quantities, integration scope, support expectations and regional procurement coordination. The most useful starting information is the destination country, the number and type of protected endpoints, whether the environment already uses FortiEDR or other Fortinet Security Fabric components, and whether the XDR design must incorporate cloud sources, third-party products or a managed service. Buyers in East Africa and other regions can also discuss related procurement through FourTeck resources such as FourTeck Africa.
Availability and fulfilment may depend on the destination, subscription region, quantity, term, vendor lead time, payment and shipping arrangements for any related hardware, local project conditions and the requested configuration or support scope. Buyers should provide the exact requirement and preferred deployment schedule before expecting commercial or implementation dates. FourTeck can then help structure the quotation and identify which parts are licenses, onboarding, configuration, support or complementary technology.
Related options and supporting technologies
FortiEDR
The endpoint detection and response foundation used in the current XDR ordering model. Suitable when the requirement is primarily endpoint protection and response rather than extended cross-source detection.
FortiAnalyzer
A central analytics and data-lake option in the Fortinet environment. The relationship to XDR should be planned around logging, incident operations and the desired source of record.
FortiGate
A documented Security Fabric integration point that can participate in enhanced response actions. Firewall sizing and subscriptions remain separate procurement decisions.
Managed XDR or MDR
Relevant when the organisation needs managed triage, monitoring or additional expert capacity. Managed service scope and deployment compatibility must be quoted separately.
Why businesses contact FourTeck for this requirement
The difficult part of an XDR purchase is usually not finding a product name. It is making sure the license structure, endpoint quantity, integrations, response scope and implementation expectations all describe the same project. FourTeck can help buyers clarify those elements before the request reaches final procurement.
This assistance is intended to help the customer prepare an accurate bill of materials and project scope. Exact licensing, availability, commercial terms, service commitments and technical compatibility remain subject to the final vendor and project confirmation.
How buyers evaluate FortiXDR in real projects
Buyers often begin with a simple question: what is the practical difference between EDR and XDR? EDR concentrates on endpoint detection and response. XDR extends the investigation and response context beyond the endpoint so that signals from other supported systems can contribute to the same incident. In Fortinet’s current product structure, that distinction is visible in the ordering tiers: the XDR option includes the endpoint discovery, protection and response capabilities and then adds extended detection across Security Fabric and supported cloud sources. For a buyer, the important implication is that XDR should be justified by the additional data and coordinated response you plan to use. If those cross-domain connections are not part of the operating model, paying for an XDR tier may not produce the expected value.
Another frequent concern is licensing quantity. Fortinet’s 2026 ordering guide shows sample XDR bundles at 25, 500, 2,000 and 10,000 endpoint levels, but sample SKUs should not be treated as a universal rule for every transaction. New-customer onboarding is also material because the same guide states that FortiCare Best Practice Service is mandatory for new deployments with EDR or XDR functionality. A useful quotation request therefore includes the endpoint count, whether this is a new customer or an expansion, the desired subscription term, current license state and whether managed XDR is being considered. This gives procurement something more actionable than a request for a generic per-user price.
Data sources are the next major decision. The most useful question is not “How many integrations does XDR support?” but “Which sources will change an incident decision in our environment?” A FortiGate may provide network context and may participate in blocking actions. FortiNAC can be relevant to device isolation. FortiMail can be relevant to malicious email. FortiAnalyzer or FortiSIEM may be part of the analytics and reporting landscape. AWS GuardDuty and Google Security Command Center are explicitly called out in current XDR ordering guidance. Third-party APIs can extend the architecture further. Each connection, however, needs permissions, version compatibility, testing and an operational owner.
This is why a connector inventory should be attached to the purchasing requirement. For each source, write down whether it only sends telemetry, receives an incident, participates in automated response or performs more than one role. The result gives engineers a configuration map and gives procurement a way to understand why certain services or platform licenses are included in the proposal.
Choose the architecture based on the information and response you need beyond endpoints, not because XDR is a newer acronym.
Standard XDR and managed XDR are separate commercial choices. Decide whether your team will operate the platform or needs managed triage and monitoring support.
Start with business-safe actions and introduce higher-impact automation after testing. A response that is technically possible may still be operationally unsuitable.
Does FortiXDR replace a SIEM?
Not automatically. XDR and SIEM solve overlapping but different operational problems. A SIEM may remain the central log, compliance and event-analysis platform while XDR provides cross-product detection, automated investigation and coordinated response. Fortinet itself documents integration between XDR-related workflows and FortiSIEM or FortiAnalyzer. Buyers should therefore define the system of record, incident workflow and reporting requirements before deciding whether any existing platform can be retired.
What should be automated first?
Begin with actions that have a low chance of interrupting business, such as enrichment, notification, case creation or response recommendations. Device isolation, credential expiry and network blocking should be introduced after the relevant teams understand the effect on business applications and recovery. A good automation plan includes exception handling, manual override and a clear owner for every action class.
How should cloud and on-premises questions be handled?
Do not rely on older deployment descriptions alone. Fortinet’s current 2026 ordering matrix lists cloud deployment as supported for the XDR tier, while on-premises and fully isolated options are shown under EDR-related deployment choices. If the project has data-residency, isolation or air-gapped requirements, ask FourTeck to confirm the exact supported architecture before the quotation is approved.
What information makes a quote more accurate?
Provide endpoint quantity, operating environments, current FortiEDR or FortiEndpoint licenses, subscription term, new or existing customer status, required Fortinet integrations, cloud sources, third-party connectors, managed-service expectations and implementation scope. Mention migration, training and documentation if needed. This allows the quote to separate software subscriptions from onboarding and professional services instead of combining them into an unclear total.
Questions security and procurement teams should answer together
Can FortiXDR coexist with our current SIEM instead of replacing it?
Yes, coexistence can be part of the design. Fortinet documents relationships with FortiSIEM, FortiAnalyzer and data-lake sources, and third-party integration can be used where supported. The important decision is what each platform owns. Keep the SIEM as the central log or compliance platform if that is required, and define whether XDR is responsible for correlation, investigation, response or only selected incident classes. Avoid creating two parallel case workflows with no agreed system of record.
How much telemetry should we connect during the first phase?
Start with sources that materially improve context or enable a high-value response. Endpoint telemetry, core Fortinet network controls and the cloud security services most relevant to your risk model are often easier to validate than a large connector catalogue. Once the team understands incident quality and response behaviour, additional sources can be introduced. This phased method makes permission problems, noisy feeds and unexpected dependencies easier to isolate.
Should every supported remediation action be automatic on day one?
Usually no. Automation should follow the organisation’s tolerance for operational impact. Low-risk notifications and enrichment can often be enabled sooner than isolation, credential or network-control actions. Define protected assets, maintenance windows, exception lists and manual approval requirements. Test the action path with realistic scenarios and make sure the operations team knows how to restore a system if an automated action creates an unintended effect.
What changes when the environment includes OT, legacy systems or mobile devices?
Compatibility and response policy require more attention. Fortinet has documented coverage extending across current and legacy endpoint platforms, mobile devices and OT-related environments, but support varies by product version and collector. A production controller should not be treated like a standard user laptop. Confirm platform support, change-control restrictions and isolation consequences before enabling any automated response that could affect operations.
How should procurement compare standard XDR with managed XDR?
Compare responsibility rather than only subscription price. Standard XDR provides the platform capabilities that your team operates. Managed XDR adds service activity and should be evaluated for monitoring scope, triage, escalation, response guidance, service hours, deployment compatibility and handoff to internal teams. The current Fortinet ordering guide lists managed XDR separately, so the quote should make the distinction clear.
What evidence should we gather before a renewal?
Review protected endpoint counts, inactive licenses, integrations still in use, response actions actually enabled, cloud sources, managed-service utilisation, storage needs and any environment changes since the original purchase. Then verify the current vendor ordering guide and co-term rules. A renewal is a good time to remove unused scope, add new required connectors or move between service options rather than automatically copying the previous order.
Frequently asked questions
Is FortiXDR a standalone hardware appliance?
No. FortiXDR is an extended detection and response software and subscription capability built around the FortiEDR foundation and the wider Fortinet security operations environment. A quotation should focus on endpoint quantity, subscription tier, integrations, onboarding and services rather than appliance throughput or physical interfaces.
How is FortiEDR related to FortiXDR?
FortiEDR provides the endpoint detection and response foundation used in the current FortiXDR model. Fortinet’s 2026 ordering guide presents an XDR tier described as Discover, Protect and Respond with XDR, extending the endpoint capabilities with cross-source detection. The exact subscription and upgrade path should be confirmed for the customer’s existing licenses.
Does FortiXDR support AWS GuardDuty and Google Security Command Center?
Current Fortinet ordering guidance lists extended detection across AWS GuardDuty and Google Security Command Center for the XDR tier. The project still needs the correct cloud permissions, connector configuration and supported product versions, so these integrations should be validated during design.
Does a standard FortiXDR subscription include managed 24×7 monitoring?
Managed XDR is shown as a separate service option in current Fortinet ordering guidance. Do not assume that managed triage or monitoring is included with every standard XDR subscription. If external monitoring is required, request the managed service scope, escalation model and commercial terms separately.
How is FortiXDR licensed?
Fortinet’s 2026 FortiEDR ordering guide lists sample XDR subscription bundles at 25, 500, 2,000 and 10,000 endpoint levels, with separate managed XDR references. Actual quantity rules, term, onboarding and upgrade or renewal path should be confirmed for the exact customer requirement before ordering.
Can FortiXDR be deployed on premises?
The current 2026 ordering matrix lists cloud deployment as supported for the XDR tier, while on-premises and fully isolated deployment options are shown for EDR-related configurations. Because older FortiXDR material describes broader deployment possibilities, buyers with on-premises or air-gapped requirements should confirm the currently supported architecture before purchase.
What information is needed for a UAE FortiXDR quotation?
Provide the endpoint quantity, current FortiEDR or FortiEndpoint licenses, required subscription term, new or existing customer status, Fortinet and third-party integrations, cloud security sources, managed-service requirement, configuration scope and preferred project timeline. FourTeck can then help structure the bill of materials and confirm current UAE availability.
Can FourTeck help plan integrations and response playbooks?
FourTeck can discuss integration, configuration and response-playbook requirements as part of a project scope. The customer should identify the systems to be connected, the actions that may be automated, business-critical exclusions and approval rules so the requested configuration reflects the organisation’s operational policies.
What should be checked before renewing FortiXDR?
Review the active endpoint count, current subscription tier, integration usage, response automation, managed-service needs, co-term requirements and any architecture changes made during the term. Renewal SKUs and vendor policy can change, so the current ordering guidance should be checked instead of automatically repeating an old part number.
Prepare the FortiXDR requirement before you commit to the license
Share your endpoint quantity, existing Fortinet environment, cloud security sources, required integrations, preferred subscription term and whether managed operations or configuration services are needed. FourTeck can help turn those details into a clearer quotation and deployment scope, while current UAE availability, licensing and vendor lead times are confirmed for the exact requirement.