---
{
  "title": "Domain or Tenant Policy Modification",
  "summary": "Domain or tenant policy modification alters centralized identity and security settings.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1484"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1484: Domain or Tenant Policy Modification",
      "url": "https://attack.mitre.org/techniques/T1484"
    }
  ],
  "editorialVersion": 2
}
---

## Central policy has a wide reach

Domain or tenant policy modification changes centralized settings that govern identities, security behavior, or trust relationships. A single administrative action can affect many users or systems. Unauthorized modification may weaken controls, change access rules, or enable continuing access beyond the actor's original foothold.

Policy changes are also ordinary administration. The investigation needs the specific setting, before-and-after values, modifying principal, target scope, time, and resulting enforcement behavior. A generic “policy changed” alert is only the beginning of that analysis.

## A security requirement changes

In a fictional academy, an identity policy is altered so a group of accounts no longer receives the expected protection. The analyst retrieves the change event and current configuration, identifies the actor, and compares the change with approved maintenance.

An emergency exception may have been authorized for a limited purpose. Check whether the actual group, duration, and conditions match that approval. An approved ticket for one account does not justify a broad tenant-wide exception.

The team reviews activity during the affected interval. A configuration change establishes a modified rule; it does not automatically prove that an actor used the weakened path. Authentication and resource records may show subsequent effects.

## Understand propagation and dependencies

Central settings may apply differently across services or take time to propagate. Verify the enforcement state relevant to the incident rather than assuming every resource changed at the same moment. Preserve the original event and configuration evidence where available.

Review who can make similar changes and how administrative authority is protected. If the modifying identity remains compromised, reverting the policy once may not prevent it from being changed again.

[[account-manipulation]] concerns changes to individual identities and access. [[least-privilege]] informs the review of policy-administration authority, while [[cloud-audit-logs]] may provide the management trail in a cloud tenant.

## Restore the intended rule with ownership

Coordinate rollback with the policy and service owners. A rushed reversal can affect legitimate access or overlook related settings. Record why the change was selected, who approved it, and how enforcement will be verified afterward.

Search for other changes made under the same authority and review access that may have been established during the exposure window. Correcting the policy does not necessarily invalidate every session or credential created while it was weakened.

For practice, compare a documented temporary exception with an unexplained broad policy change. Identify the scope, approval, effective-state, and subsequent-activity evidence needed to distinguish them. Write separate statements about configuration and confirmed use. [[incident-response]] coordinates the decisions, and [[incident-reporting]] preserves the remaining uncertainty.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[scheduled-task-job]]
- [[rogue-domain-controller]]