---
title: Understanding your controlled support access security posture
summary: null
url: >-
  https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/understanding-your-controlled-support-access-security-posture
---

Controlled support access lets you govern how Fastly changes your account. The security posture you build with it follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). Any access should be the least the task requires, and no more. [Zero standing privilege](https://en.wikipedia.org/wiki/Zero_standing_privileges) goes one step further to ensure access privileges do not change between sessions, only the read-only access Fastly always has. You grant change access when it's needed, scoped and time-limited, and it ends on its own or can be specifically revoked by you. Governing third-party access this way, and keeping a record of it, is a control that compliance frameworks such as SOC 2, PCI DSS, and FedRAMP ask you to demonstrate.

Once [enabled](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/getting-started-with-controlled-support-access/), controlled support access takes effect immediately. Fastly keeps its read-only access, but any change to your account requires your approval first. Nothing changes until you allow it.

The decisions that apply that principle to your account are how you grant access, how long you grant it for, how you review it, and what your audit log shows. This guide assumes you know [how the access itself works](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/about-controlled-support-access/).

> **IMPORTANT:** 
>
> Controlled support access does not apply to [Fastly Next-Gen WAF](https://docs.fastly.com/products/fastly-next-gen-waf) or [Bot Management](https://docs.fastly.com/products/bot-management).
>
>
>
>

## Choosing when to grant access

Controlled support access provides two ways to give Fastly Support the change access it needs. Which one fits depends on whether the work is unplanned or something you can see coming, and most security postures use both.

The default is to wait for a request. Support requests access when a situation calls for it, stating a duration and a reason, and a superuser or support admin approves or denies it. Nothing changes in your account until you approve. This suits unplanned work, where the reason for access can't be known ahead of time. Each grant stays tied to a specific request you authorized, which is the record an audit looks for.

The alternative is to grant access ahead of need. A scoped, time-limited session opened before Support asks puts access in place for work you can anticipate: a planned migration, a configuration change you've requested help with, or a high-traffic event where waiting on an approval would delay Support at the moment access is needed. Because the grant precedes any specific incident, it should be short and scoped to the window it covers.

The two aren't exclusive. A security posture typically uses approve-on-request day to day and a proactive grant for a known window.

The choice between them depends on how reachable your superusers and support admins are. Approve-on-request depends on one of them being available, and requests can arrive at any hour. If your approvers share a time zone and schedule, requests can be approved as they come. If they are few, or spread across time zones, some requests will arrive when no one is available to approve them. [Proactive grants](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/managing-controlled-support-access-requests/) cover the windows you can anticipate, but not the ones you can't. Coverage for the rest depends on how quickly an approver can respond when a request arrives.

## Sizing access to the work

Every session you approve or grant has a duration: long enough for Support to finish, short enough that access doesn't outlast the reason for it. Access that ends when the work does is another property an auditor expects to see. Two things about how sessions work inform that duration.

First, a session can't be extended once it's running. If Support needs more time, they submit a new request, which creates a new session with its own approval and its own audit record. Work saved or staged during the first session remains in place and can be resumed under the new one. Because a session that expires mid-task costs only a new request, not lost progress, a duration can be sized to the expected work rather than the worst case.

Second, what a session permits comes in two forms, one lower-risk than the other. Write actions create or stage configuration without affecting live traffic, such as drafting a service version. Enforcing actions take effect on production immediately, such as activating a service, deploying a security rule, or blocking traffic. Both require an approved session, but a session with enforcing actions can change what users experience at once, so it warrants the shortest duration and the closest attention. A request limited to staging work carries less risk over a longer window. A request covering enforcing actions should be sized tight.

Together, these give you a way to size any request: what the work is, whether it only stages or also enforces, and the shortest window that lets Support finish. If more time is needed, a new request costs little against access left open longer than the work requires.

You set the duration when you grant access proactively, and read it on a request before approving. [Managing controlled support access](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/managing-controlled-support-access-requests/) shows where those controls are.

## Overseeing access

A security posture covers not just how you grant access, but how you watch it while it's active and review it afterward.

Most sessions end without any action from you. Support releases its work when finished, and a session that isn't released ends when its approved time expires. Resuming access then takes a new request. You can also end a session early, before Support has released it and before the time is up, which is the control you use when access should stop regardless of the state of the work, because the situation changed or the access is no longer warranted.

The control panel shows access in three states: pending requests awaiting a decision, active sessions, and a history of past requests, including approvals, denials, expirations, and early terminations. Pending requests are the ones that need a decision now. Active sessions show what's open at any moment. History shows what access has looked like over time, which is what you review a posture against.

How often you review depends on how much Support access you grant, more when access is frequent, less when it's rare. Who reviews, and how often, is itself part of your security posture, and a review process auditors can see is part of demonstrating it.

You end a session early, and view pending, active, and past access, from the same place you approve requests, described in [Managing controlled support access](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/managing-controlled-support-access-requests/).

## Interpreting your audit trail

The audit log records every decision you make about access, and it's where you verify your security posture.

Every controlled support access event appears in the log: requests, approvals, denials, session starts and ends, and the write and enforcing actions Support takes during a session. A session's end is recorded whether Support releases it, you end it early, or the approved time expires. Each entry identifies what Fastly did, the time, the scope of the access, and the duration of the session. Together they show who accessed your account, what they did, and when, which is the record you draw on for security reviews and investigations, and the evidence you provide for compliance.

The log is complete for access that changes your account. Every request, approval, denial, session start and end, and write and enforcing action is recorded, whatever the circumstances behind it. That completeness is what makes the log reliable as a check. It's also what lets the log serve as evidence, since a complete record of third-party access is what an audit is built on. A selective record couldn't tell you what happened. Read-only access is the exception: the viewing access Fastly always has doesn't appear, because the log records change, not viewing. So every entry represents a change made under approved access. A session showing enforcing actions outside the scope you approved, or a duration longer than the work should have taken, appears in the log.

What the log will show also bears on the decisions before it. The scope and duration you approve are the scope and duration recorded, so a narrowly approved request reads cleanly afterward and a loosely approved one leaves more to account for. Sizing access tight keeps the audit trail legible.

[Monitoring account activity with the audit log](https://www.fastly.com/documentation/guides/organizations-and-accounts/account-activity-and-notifications/monitoring-account-activity-with-the-audit-log/) describes the audit log itself and how to read it.

> **HINT:** You make every access decision except one. In a genuine [emergency](https://www.fastly.com/documentation/guides/organizations-and-accounts/company-account-settings/controlled-support-access/about-controlled-support-access/#emergency-access) that threatens platform stability, Fastly may need to act before your approval can be obtained.