How would you handle a breaking change to a shared Terraform module that genuinely needs to reach all consumers within a specific timeframe, like a security fix?

Treat it as an active push, not a passive release: publish the fix as a new patch version (never silently mutate an existing tagged version), then proactively reach out to every known consumer with a specific deadline and clear upgrade instructions — don't rely on consumers discovering it themselves — and if the deadline is genuinely non-negotiable, escalate through whatever organizational authority can mandate the upgrade for teams that don't respond in time, since version-pinning alone gives no mechanism to force an upgrade.

The core tension is that Terraform's version-pinning model is specifically designed to let consumers control their own upgrade timing — which is exactly the right default for normal changes, but is structurally the wrong default for a genuinely urgent fix, since nothing about a normal release forces anyone to actually pull it in on any particular timeline.

Publish as a proper new version, never mutate history: even under time pressure, the fix should go out as a new, correctly-versioned release (a patch version bump, following semantic versioning) — never by force-overwriting an existing tag's content, which breaks the fundamental guarantee that a given version reference always points to the same content, and would confuse or break any tooling/process relying on that guarantee.

Proactive, direct outreach — don't rely on discovery: publishing the new version alone accomplishes nothing if consumers don't know to look for it — a security-relevant module fix needs the module owner to actively reach out to every known consumer (a direct message, an email, a tracked ticket per consumer team) specifying the vulnerability, the required version, and a concrete deadline, rather than assuming teams will notice a new release on their own initiative within any useful timeframe.

Provide a low-friction upgrade path: since the ask is urgent, minimizing the friction of actually adopting the fix matters — clear, specific upgrade instructions (exactly what to change in the consumer's version pin), and ideally an automated way to verify who has and hasn't upgraded yet (checking Terraform Cloud workspace states, or a similar mechanism, for which module version each consumer is actually running) turns "did everyone upgrade" from a manual chase into a trackable, verifiable process.

Escalate for non-responsive consumers if the deadline is genuinely non-negotiable: version pinning gives consumers technical control over their own upgrade timing — there's no mechanism to force a Terraform module upgrade the way, say, a centrally-enforced policy engine could block non-compliant infrastructure. If a deadline is genuinely non-negotiable (an active vulnerability with a compliance-driven remediation SLA, for instance), reaching non-responsive teams requires organizational escalation (their management, a security team's authority) rather than a purely technical mechanism, since Terraform itself has no built-in way to compel an upgrade.

• Publish the fix as a proper, correctly-versioned new release — never mutate an existing tag's content, even under urgency.
• Proactively and directly notify every known consumer with a specific deadline — don't rely on them discovering the release on their own.
• Track which consumers have actually upgraded (via workspace state inspection or similar) to turn "did everyone comply" into a verifiable process, not a guess.
• Version pinning gives consumers technical control over upgrade timing with no built-in force mechanism — a genuinely non-negotiable deadline requires organizational escalation, not just a technical push.

• Terraform: Module versioning
• Semantic Versioning 2.0.0