> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/trust/compliance/sla.md).

# The 72-hour SLA

Seal handles **critical- and high-severity vulnerabilities within 72 hours of public disclosure**. For each newly disclosed vulnerability that meets this severity bar, Seal commits to producing a sealed iteration of every affected package within that window.

Lower-severity vulnerabilities (medium and low) are handled in accordance with the contractually agreed SLA on each customer's account.

## Scope of the 72-hour SLA

The 72-hour SLA covers vulnerabilities that can be **backported without breaking changes to the consuming package's behavior**. This is the vast majority of vulnerabilities Seal sees: the fix is local to a function or a small region of code, the public API is unaffected, and a drop-in replacement is straightforward.

For the small number of vulnerabilities that cannot be cleanly patched without breaking changes, the SLA does not apply. Those cases are handled through Seal's [private versions](/discovering/private-versions.md) flow: a breaking-change patch is built per request, made available to customers who opt in and accept the compatibility risk, and not shipped automatically. The timeline on a private version reflects the complexity of the breaking change rather than the 72-hour window.

## What "handled" means

Within the 72-hour window, Seal:

* Confirms whether the vulnerability is in scope.
* Produces a sealed iteration of every affected package that addresses the vulnerability.
* Publishes the iteration, its [code diff](/trust/code-diff.md), its [attestations](/trust/attestations.md), and its signature.

After the iteration is published, your build pulls it on its next CI run (under the appropriate deployment method).

## What is not covered

* Vulnerabilities in packages outside Seal's coverage.
* Customer-side adoption. The SLA covers when Seal publishes the sealed iteration; how quickly your build picks it up depends on your CI cadence and deployment method.
* Severity reclassifications that happen after the initial disclosure. If a vulnerability is initially scored low and is later raised to high, the clock starts at the moment it crosses the high-or-critical threshold.

## When 72 hours is too long

In some cases customers need an iteration faster than 72 hours, for instance when a vulnerability is being actively exploited in their environment. Contact [your Seal account team](/introduction/audience-guides/security-leader.md) for expedited handling. Seal's standard process can be accelerated when the circumstances warrant.

## Support channels

24/7 support is available. The primary channel is the joint Slack or Teams channel set up with each customer at onboarding. The fallback is `support@sealsecurity.io`. For urgent issues outside business hours, the address `emergency@sealsecurity.io` triggers the Seal on-call rotation.

## Related

* [Triggering Generate fix](/discovering/generate-fix.md): the customer-side action that requests a sealed iteration on demand.
* [Private versions](/discovering/private-versions.md): the path for vulnerabilities that need a breaking-change patch.
* [Frameworks Seal helps you meet](/trust/compliance/frameworks.md)