☁️ Azure Sentinel Microsoft Threat Intelligence Data Connector Terraform Module — ⚠️ DEPRECATED

Brings Microsoft's emerging-threat-feed indicators into a Microsoft Sentinel workspace (azurerm_sentinel_data_connector_microsoft_threat_intelligence). Microsoft Defender Threat Intelligence reached end of life on 1 August 2026 and the standalone MDTI SKU is retired; its capabilities now arrive at no extra cost through the Microsoft Defender portal. See DEPRECATED.md. Targets hashicorp/azurerm ~> 4.0.

⚠️ Read this before anything else

Milestone	Date
Microsoft Defender Threat Intelligence reaches end of life; the standalone MDTI SKU is retired	1 August 2026 — elapsed
Sentinel's Azure portal experience retires	31 March 2027

Microsoft: "All MDTI capabilities are now available at no extra cost through the Microsoft Defender portal to any customer with Microsoft Defender or Microsoft Sentinel."

The purchasable product in front of this connector no longer exists, so any procurement step in an older runbook — an MDTI subscription, an API-access SKU, a sales conversation to unlock the feed — describes something retired. The capability was folded in rather than withdrawn: it is included for Defender and Sentinel customers through the Defender portal. This does NOT mean the connector has stopped collecting — that is established only for the sibling Threat Intelligence Platforms connector, so verify ingestion in the workspace rather than inferring it. The provider schema flags nothing. See DEPRECATED.md, and note that this module deliberately adds no new validation, because a validation {} failure blocks terraform destroy and destroy is now the point.

• 🔎 Brings Microsoft's own emerging-threat-feed indicators into the Sentinel workspace.
• ✅ The lookback date is REQUIRED here — and that required-ness is doing real work: it makes the epoch-default trap its pair sibling carries impossible on this resource.
• ⚠️ And it is force-new, unlike the TAXII connector's equivalent field — so changing it costs a gap in collection and a fresh import.
• ⚠️ tenant_id looks like a cross-tenant switch and is not. Omit it.
• 🔴 Nothing is updatable. Every argument is force-new.
• 🔗 It is one of the threat-intelligence alert rule's possible upstreams — that rule supplies no indicators of its own.
• 🔒 No credential is accepted and none is emitted.

💡 Why it matters: Four arguments, and the one that matters is required rather than optional — which is the whole difference between this module and its sibling. A required argument is doing the job a warning would otherwise have to do, and it is worth noticing when two resources look otherwise identical.

📅 Azure portal retirement - March 31, 2027

Microsoft states that after March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal, and that customers using Microsoft Sentinel in the Azure portal will be redirected to the Defender portal. Since July 2025 many new customers are onboarded and redirected to the Defender portal automatically.

This does not change what this module manages. azurerm_sentinel_* are ARM resources and Terraform talks to ARM, not to a portal, so these resources continue to exist and stay manageable from code across that date. What moves is the management experience - runbooks, screenshots, analyst training, and any procedure that ends in a human clicking through Sentinel in the Azure portal. Plan that transition on its own schedule; this module emits management_moves_to_the_defender_portal so the date reaches plan output and inventory reports rather than living only in documentation.

Reference: https://learn.microsoft.com/azure/sentinel/overview#microsoft-sentinel-in-the-azure-portal-retirement-timeline

If this module saves you time, please consider supporting its continued development:

• ⭐ Star the repository on GitHub.
• 🤝 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart LR
  law["terraform-azurerm-log-analytics-workspace: every connector writes into this workspace, and its RETENTION bounds how far back any detection built on the data can look"]
  onboard["terraform-azurerm-sentinel-log-analytics-workspace-onboarding: THE GATE. No connector works until Sentinel is onboarded, and DESTROYING IT OFFBOARDS SENTINEL."]
  wsid["and every connector takes log_analytics_workspace_id FROM THAT MODULE'S workspace_id OUTPUT, not from the workspace module's id - same string, but reading it through the onboarding module is what makes Terraform ORDER ONBOARDING FIRST"]
  clones["THE NINE TENANT-SCOPED CONNECTORS, all with an IDENTICAL three-argument shape: name, workspace, and an optional tenant_id. NOTHING is updatable, so every argument is force-new and the schema omits the update timeout."]
  list["azure-active-directory. azure-advanced-threat-protection. dynamics-365. microsoft-defender-advanced-threat-protection. microsoft-threat-protection. office-365-project. office-atp. office-irm. office-power-bi."]
  tenant["AND tenant_id IS A TRAP: it is optional and computed, so it defaults to the running account's tenant - and the provider states that ONLY the same tenant is allowed, because cross-tenant collection IS NOT SUPPORTED. An argument that looks like it enables multi-tenant collection and does not."]
  preview["all nine sit on a PREVIEW API version, which is worth knowing before depending on their argument surface"]
  others["THE OTHER NINE CONNECTORS ARE NOT CLONES: azure-security-center and iot take a SUBSCRIPTION id instead. microsoft-cloud-app-security and office-365 carry per-stream TOGGLES. microsoft-threat-intelligence and threat-intelligence take a LOOKBACK DATE. aws-cloud-trail and aws-s3 take an AWS ROLE ARN. threat-intelligence-taxii takes a URL, a collection and CREDENTIALS."]
  rules["AND CONNECTORS ARE THE UPSTREAM THAT DECIDES WHETHER A DETECTION CAN FIRE AT ALL"]
  ms["terraform-azurerm-sentinel-alert-rule-ms-security-incident: its product_filter takes LEGACY product names, and three of them map exactly onto connectors in this batch - Azure Advanced Threat Protection, Microsoft Defender Advanced Threat Protection, and Office 365 Advanced Threat Protection."]
  sched["terraform-azurerm-sentinel-alert-rule-scheduled and -nrt: a query against a table no connector is filling DEPLOYS CLEANLY AND NEVER FIRES"]
  anom["terraform-azurerm-sentinel-alert-rule-anomaly-built-in: emits required_data_connector, which is Microsoft's own statement of which connectors its detection needs. Cross-check it against what is actually deployed."]
  silent["SO THE FAMILY RISK IS THE SAME ONE AS THE ALERT RULES, ARRIVING FROM UPSTREAM: a perfectly configured detection with no connector behind it is SILENT, and silence is indistinguishable from the good outcome."]

  law -->|"id"| onboard
  onboard -->|"workspace_id"| wsid
  wsid -->|"log_analytics_workspace_id"| clones
  wsid -->|"log_analytics_workspace_id"| others
  clones -->|"which nine"| list
  tenant -->|"read this first"| clones
  preview -->|"stability"| clones
  clones -->|"fills tables"| rules
  others -->|"fills tables"| rules
  rules -->|"product_filter upstream"| ms
  rules -->|"query tables"| sched
  rules -->|"required_data_connector"| anom
  silent -->|"the shared failure mode"| rules

  classDef me fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class onboard keystone;
  class clones me;
  class law,wsid,list,tenant,preview,others,rules,ms,sched,anom,silent sib;

flowchart TB
  pair["TWO CONNECTOR MODULES SHARE THIS EXACT SHAPE: microsoft-threat-intelligence and threat-intelligence. name, log_analytics_workspace_id, an optional tenant_id, and a LOOKBACK DATE. So this diagram is the same in both READMEs."]
  diff["BUT ONE FIELD DIFFERS IN A WAY THAT MATTERS MORE THAN ANY OTHER DIFFERENCE IN THIS FAMILY: on microsoft-threat-intelligence the lookback is REQUIRED, and on threat-intelligence it is OPTIONAL and DEFAULTS TO THE UNIX EPOCH."]
  trap["so threat-intelligence carries the same trap as the TAXII connector: leave the lookback unset and the first poll imports EVERYTHING the feed has ever published - a real one-off ingestion bill that arrives without warning"]
  saved["AND ITS SIBLING CANNOT MAKE THAT MISTAKE, because the provider makes the field REQUIRED there. A required argument is doing the job a warning would otherwise have to do, which is worth noticing when the two resources look otherwise identical."]
  rfc["both are validated for RFC 3339 shape with can(timeadd), because a PROVIDER schema check only fires against a literal in a resource block and does not reach through a module boundary. NOTE what is NOT true: an unparseable value does not fall back to the epoch. The provider discards the parse error and would send Go zero time, 0001-01-01, and the schema validator makes that path unreachable anyway. The epoch matters only as the OPTIONAL side default."]
  fnew["AND UNLIKE THE TAXII CONNECTOR, THE LOOKBACK HERE IS FORCE-NEW. Changing it destroys and recreates the connector, so you get a GAP in collection AND a fresh import from the new date - two costs from one edit."]
  nothing["in fact NOTHING is updatable on either resource: every argument is force-new and the schema OMITS the update timeout, so writing update into the resource's timeouts block fails at plan"]
  tenant["tenant_id is optional, computed and force-new, and the provider states that ONLY THE SAME TENANT IS ALLOWED because cross-tenant collection is not supported - so the computed default is the only workable value. Omit it."]
  ws["log_analytics_workspace_id wants the workspace's ARM RESOURCE ID, wired from the ONBOARDING module's workspace_id output so Terraform orders onboarding first. A bare GUID is rejected at plan time."]
  ti["AND THE INDICATORS THESE BRING IN ARE WHAT THE THREAT-INTELLIGENCE ALERT RULE MATCHES AGAINST. That rule supplies none of its own, so these connectors are exactly the upstream whose absence makes it a detection that CANNOT FIRE while looking perfectly healthy."]
  this["one of the two lookback-scoped threat-intelligence connector modules"]
  keystone["the azurerm_sentinel_data_connector resource for that one feed, named this"]

  pair -->|"but"| diff
  diff -->|"so"| trap
  trap -->|"whereas"| saved
  saved -->|"and"| rfc
  rfc -->|"validated"| this
  fnew -->|"in fact"| nothing
  nothing -->|"lifecycle"| this
  tenant -->|"posture"| this
  ws -->|"wiring"| this
  ti -->|"why it matters"| this
  this -->|"brings threat-intelligence indicators in"| keystone

  classDef me fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class this me;
  class keystone keystone;
  class pair,diff,trap,saved,rfc,fnew,nothing,tenant,ws,ti sib;

ℹ️ That diagram is shared with terraform-azurerm-sentinel-data-connector-threat-intelligence, deliberately: within this pair the schema, the lifecycle and the failure modes are identical. What differs is which data arrives — and, for the lookback pair, one field's required-ness, which example 3 is about.

Resource inventory

Schema notes that bite — confirmed against the live provider schema and its documentation:

• ✅ microsoft_emerging_threat_feed_lookback_date is REQUIRED — the provider gives it no default, so the epoch trap its pair sibling carries cannot happen here.
• ⚠️ And it is force-new, unlike the TAXII connector's lookback_date, which updates in place.
• tenant_id is optional, computed and force-new, and restricted to the running account's tenant.
• The argument name is long and unlike anything else in the family — microsoft_emerging_threat_feed_lookback_date, not lookback_date.
• 🔴 Every argument is force-new, and the schema omits the update timeout — so every change is a destroy-and-recreate, which for a connector is a gap in collection.
• ⚠️ An update key passed to this module's timeouts variable is silently discarded, not rejected.
• The Resource ID ends /dataConnectors/<name> under the workspace.
• No tags. Tag the workspace.
• lifecycle is not valid inside a module block, so a caller cannot add prevent_destroy.

Contributor or Owner at the same scope also work, and are broader than needed.

ℹ️ The entitlement question this connector used to raise has closed. Microsoft Defender Threat Intelligence reached end of life on 1 August 2026: the standalone MDTI SKU is retired, and MDTI's capabilities are now included at no extra cost through the Microsoft Defender portal for any customer with Microsoft Defender or Microsoft Sentinel. So there is nothing to purchase in front of this connector, and any older instruction to buy an MDTI subscription or an API-access SKU describes a product that no longer exists.

ℹ️ No product-side licence or tenant setting is documented for this connector, which makes it one of the more straightforward in the family from a prerequisites point of view.

• The Log Analytics workspace already onboarded to Microsoft Sentinel — wire log_analytics_workspace_id from that module's workspace_id output so Terraform orders the two correctly.
• A decision about the lookback date, since the provider requires one. Something recent is the usual choice.
• Retention long enough to be useful. Sentinel has no storage of its own, so the workspace's retention bounds what any detection on this data can look back at.

terraform-azurerm-sentinel-data-connector-microsoft-threat-intelligence/
├── providers.tf   # required_version + the pinned azurerm provider. No provider block.
├── variables.tf   # name, log_analytics_workspace_id,
#                  # microsoft_emerging_threat_feed_lookback_date (REQUIRED),
#                  # tenant_id, timeouts
├── main.tf        # the keystone, one resource
├── outputs.tf     # id first, then the distinctive facts, then the constant posture flags
├── README.md      # this document
├── SCOPE.md       # the cross-module contract
├── DEPRECATED.md  # the retirement dates, what still works, and the migration sequence
├── LICENSE        # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "dc_ms_ti" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-sentinel-data-connector-microsoft-threat-intelligence.git?ref=v1.0.0"

  name = "microsoft-threat-intelligence"

  # ⚠️ From the ONBOARDING module, not the workspace module. See example 1.
  log_analytics_workspace_id = module.sentinel.workspace_id

  # ✅ REQUIRED — the provider gives no default, which is what prevents the
  # epoch trap this module's sibling carries. See example 3.
  microsoft_emerging_threat_feed_lookback_date = "2026-06-01T00:00:00Z"

  # tenant_id deliberately omitted — only the running account's tenant is supported.
}

ℹ️ The caller configures the provider, its authentication, and the mandatory features {} block. This module declares none of them.

⚠️ Read example 3 — the required lookback here is the interesting difference from this module's sibling.

Consumes

Emits

No credential is accepted and none is emitted.

# ✅ This creates the dependency edge.
log_analytics_workspace_id = module.sentinel.workspace_id

# ⚠️ Identical string. No dependency on onboarding.
log_analytics_workspace_id = module.law.id

# ❌ Rejected at plan time.
log_analytics_workspace_id = azurerm_log_analytics_workspace.example.workspace_id

Brings in:  Microsoft's EMERGING THREAT FEED indicators
            (Microsoft's own threat-intelligence, curated from its global signal)

THIS module:                                   REQUIRED, no default
  microsoft_emerging_threat_feed_lookback_date

Its pair sibling (threat-intelligence):        OPTIONAL, defaults to 1970-01-01T00:00:00Z
  lookback_date

The TAXII connector:                           OPTIONAL, defaults to 1970-01-01T00:00:00Z
  lookback_date

microsoft_emerging_threat_feed_lookback_date = "2026-06-01T00:00:00Z"

This module:            microsoft_emerging_threat_feed_lookback_date  FORCE-NEW
The TAXII connector:    lookback_date                 UPDATES IN PLACE

Error: Invalid value for variable

  microsoft_emerging_threat_feed_lookback_date must be a valid RFC 3339 timestamp, for
  example 2026-06-01T00:00:00Z.

# ✅ Recommended: omit it.
# tenant_id = ...

THIS CONNECTOR                      the threat-intelligence ALERT RULE
   brings indicators in       ->       matches log data against them
                                       and supplies NONE of its own

This resource's ARM API version is a PREVIEW version.

Force-new: name  log_analytics_workspace_id  microsoft_emerging_threat_feed_lookback_date  tenant_id
Updatable: nothing

timeouts = { create = "30m", read = "5m", delete = "30m" } # ✅

timeouts = { create = "30m", update = "30m" } # ⚠️ the `update` key is SILENTLY DISCARDED

output "dc_ms_ti_review" {
  value = {
    id       = module.dc_ms_ti.id
    collects = module.dc_ms_ti.collects       # what arrives
    upstream = module.dc_ms_ti.is_upstream_of_detections # always true
    lookback = module.dc_ms_ti.microsoft_emerging_threat_feed_lookback_date
    tenant   = module.dc_ms_ti.tenant_id
  }
}

terraform import 'module.dc_ms_ti.azurerm_sentinel_data_connector_microsoft_threat_intelligence.this' \
  "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-sentinel/providers/Microsoft.OperationalInsights/workspaces/law-sentinel-prod/providers/Microsoft.SecurityInsights/dataConnectors/microsoft-threat-intelligence"

terraform destroy on this module:
  removes the connector    ->  collection STOPS
                           ->  the workspace, its tables and existing data SURVIVE
                           ->  every rule built on this data stays valid and goes SILENT

provider "azurerm" {
  features {}
}

module "rg" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-resource-group.git?ref=v1.0.0"

  name     = "rg-sentinel-prod"
  location = "eastus"
}

module "law" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-log-analytics-workspace.git?ref=v1.0.0"

  name                = "law-sentinel-prod"
  resource_group_name = module.rg.name
  location            = module.rg.location
  sku                 = "PerGB2018"
  retention_in_days   = 90
}

# ── The gate ───────────────────────────────────────────────────
module "sentinel" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-sentinel-log-analytics-workspace-onboarding.git?ref=v1.0.0"

  workspace_id = module.law.id
}

# ── THE CONNECTOR: Microsoft's own indicators, no credential needed ────────
module "dc_ms_ti" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-sentinel-data-connector-microsoft-threat-intelligence.git?ref=v1.0.0"

  name                       = "microsoft-threat-intelligence"
  log_analytics_workspace_id = module.sentinel.workspace_id

  # REQUIRED — which is what prevents the epoch trap (example 3). Force-new (example 4).
  microsoft_emerging_threat_feed_lookback_date = "2026-06-01T00:00:00Z"

  # tenant_id omitted (example 5).
}

# ── The rule that matches against those indicators, and supplies none itself ──
module "rule_ti_matching" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-sentinel-alert-rule-threat-intelligence.git?ref=v1.0.0"

  name                       = "ti-map-ip-to-signin"
  log_analytics_workspace_id = module.sentinel.workspace_id
  alert_rule_template_guid   = var.ti_template_guid

  # Orders creation only — it cannot make indicators exist (example 6).
  depends_on = [module.dc_ms_ti]
}

resource "azurerm_management_lock" "sentinel" {
  name       = "sentinel-no-delete"
  scope      = module.law.id
  lock_level = "CanNotDelete"
  notes      = "Deleting connectors leaves gaps in collection that nothing reports"
}

output "collection_posture" {
  value = {
    collects = module.dc_ms_ti.collects
    lookback = module.dc_ms_ti.microsoft_emerging_threat_feed_lookback_date

    # Active, which is necessary and NOT sufficient — it needs the connector above.
    rule_active = module.rule_ti_matching.is_active
  }
}

There is no tags variable — the provider exposes none on Sentinel data connectors.

# See variables.tf — the distinctive checks are quoted in the examples above.

🔒 No credential is accepted and none is emitted.

• The required lookback is treated as the module's most interesting property, because it is the one thing that distinguishes this resource from a near-identical sibling — and what it prevents is a real, expensive trap. A required argument doing the job a warning would otherwise have to do is worth naming.

• No epoch-default flag is emitted here, deliberately. Its sibling and the TAXII connector both emit pulled_entire_history because their lookback can silently be the epoch; here the provider makes that impossible, so a flag would always read false and imply a risk that does not exist.

• The unusual argument name is called out. microsoft_emerging_threat_feed_lookback_date is unlike anything else in the family, and copying the sibling's shorter lookback_date across produces an "unsupported argument" error that reads as a module defect.

• The force-new lookback is contrasted with the TAXII connector's updatable one. The same conceptual field has different lifecycles across two resources in one family, and only one of them makes a lookback change cheap.

• collects is emitted as a constant string, which is unusual and earns its place. A connector's Resource ID and ARM name say nothing about the data, and "what can we detect on?" is the question a coverage review actually asks.

• is_upstream_of_detections is a constant true for the fact it makes visible, not for the value. Destroying a connector breaks no rule's configuration and makes every rule built on its data permanently silent — an asymmetry the provider models nowhere.

• depends_on is explicitly not recommended for the connector-to-rule relationship. Creation order is not the problem: a rule created before its data simply finds nothing until data arrives.

• The pair shares one shape diagram and one generated skeleton deliberately. Within the pair the schema, lifecycle and failure modes are identical; inventing distinctions a reader would then have to check is worse than saying plainly that they are the same.

• Before the first apply: choose a considered lookback. It is required, and force-new.
• Before setting tenant_id: it cannot vary, so omitting it is strictly better.
• Before changing the lookback later: it costs a gap in collection plus a fresh import.
• After the first apply: check indicators are arriving — the alert rule cannot tell you.

terraform init -backend=false
terraform validate
terraform fmt -check

• Pin the source to a tag — ?ref=v1.0.0 — never a branch.
• Plan-only from here. A human applies from CI.
• 🔴 Any change is a destroy-and-recreate, and therefore a gap in collection. Read plans carefully.
• ⚠️ A destroy stops collection and leaves every dependent rule valid and silent. Existing data survives.
• ⚠️ The lookback is force-new here (unlike on the TAXII connector), so changing it costs a gap plus a fresh import.
• ℹ️ Prefer terraform import over creating a connector that already exists in the portal.
• ℹ️ To stop managing without stopping collection, use terraform state rm.
• ℹ️ After the first apply, confirm data is arriving in the Sentinel data-connectors blade.

terraform validate and terraform fmt -check are the offline gate. They confirm:

• log_analytics_workspace_id is a Microsoft.OperationalInsights/workspaces ARM Resource ID — a bare GUID is rejected;
• name is non-empty;
• microsoft_emerging_threat_feed_lookback_date is present — it has no default, so Terraform requires it — and is a valid RFC 3339 timestamp;
• tenant_id, when set, is a GUID;
• the timeouts variable's object type declares only create, read and delete;
• no output is sensitive, because nothing sensitive is accepted;
• the module declares no provider block.

💡 These were proved by evaluating the conditions in terraform console inside the module — which does fire root-module variable validations, unlike terraform validate on a calling configuration. A bare GUID in the workspace field and a 01/06/2026 lookback both fail. The lookback's required-ness is a property of its declaration: a variable with no default is required by Terraform's own semantics, so it needs no separate test.

What only plan and apply exercise:

• whether the workspace exists and is onboarded to Sentinel;
• whether the identity holds Microsoft Sentinel Contributor.

What no Terraform command checks at any stage:

• 🔴 whether any indicators have arrived, and therefore whether the threat-intelligence alert rule can fire at all;
• how much data the first sync will import for a given lookback date;
• whether the feed is enabled for this tenant on Microsoft's side.

Outputs:

collects                                     = "Microsoft emerging-threat-feed indicators"
id                                           = "/subscriptions/00000000-.../dataConnectors/microsoft-threat-intelligence"
is_upstream_of_detections                    = true
log_analytics_workspace_id                   = "/subscriptions/00000000-.../workspaces/law-sentinel-prod"
microsoft_emerging_threat_feed_lookback_date = "2026-06-01T00:00:00Z"
name                                         = "microsoft-threat-intelligence"
tenant_id                                    = "00000000-0000-0000-0000-000000000000"

✅ The lookback is always populated, because the provider requires it — which is why there is no pulled_entire_history flag here and there is one on this module's sibling (example 3).

ℹ️ tenant_id is populated despite being omitted — it is computed from the running account's tenant.

• azurerm_sentinel_data_connector_microsoft_threat_intelligence — provider documentation.
• Microsoft Sentinel data connectors — what connectors do, and the gallery this one appears in.
• Microsoft Defender Threat Intelligence data connector — what Microsoft's feed contains.
• Microsoft Sentinel roles and permissions — the RBAC table above.
• Sibling modules: terraform-azurerm-sentinel-log-analytics-workspace-onboarding, its pair sibling terraform-azurerm-sentinel-data-connector-threat-intelligence, the nine tenant-scoped connector clones, and the five substantive connectors (...-aws-cloud-trail, ...-aws-s3, ...-threat-intelligence-taxii, ...-microsoft-cloud-app-security, ...-office-365).
• MDTI reaches end of life, August 1, 2026 — the retirement of the standalone SKU.
• This module's DEPRECATED.md — the retirement dates and the migration sequence.
• This module's SCOPE.md.

💙 "Infrastructure as Code should be standardized, consistent, and secure."