Support access to customer tenants: the standing-authority problem

A customer buys an identity platform to control who reaches their data. The support organisation running that platform holds a path into their tenant that the customer cannot see, cannot gate, and learns about only when something goes wrong.

Part of Privileged identity and account recovery

The capability nobody can remove

Support engineers need to reproduce customer problems. Reproducing a problem in a configuration you cannot see is close to impossible, so every mature platform builds an impersonation path.

The question is not whether it exists. It is who authorises each use of it.

Most platforms sit in the first two rows. The third is a meaningful improvement and is where the better vendors have landed.

The diagnostic-artefact problem

Support workflows routinely ask customers to upload a HAR capture, a debug bundle or a log archive. These artefacts are extraordinarily rich.

• Session cookies and bearer tokens, live at capture time
• Authorization headers on every recorded request
• Full request and response bodies, including customer data
• Internal hostnames, service topology and identifiers

A support system holding thousands of these is a higher-value target than most of the tenants it serves, because a single compromise yields working credentials for many of them at once.

Redaction tooling helps and is rarely complete. Token formats change, custom headers are missed, and the customer uploading the file usually does not know what is in it.

What a customer-gated design looks like

# Support engineer opens a customer tenant

1. Engineer requests access, stating scope and reason.

2. The customer's designated administrator sees:
     "Grant support access to your tenant
      Engineer:  [named individual, vendor identity]
      Scope:     read-only, billing configuration
      Duration:  4 hours from acceptance
      Reason:    ticket #48210 — invoice discrepancy"

3. Administrator signs that statement with their own credential.

4. The platform's impersonation path requires a valid, unexpired,
   unrevoked grant. No grant → access denied, including to staff
   with the support role.

5. Actions taken under the grant are recorded against both
   identities and exported to the customer.

Step four is what distinguishes this from a policy. If the check is enforced in the access path rather than in a runbook, the vendor's own administrators cannot bypass it without a code change.

Why vendors resist, and the answer

The objection is real: an outage at 2am cannot wait for a customer administrator to wake up and sign something.

Two responses, both practical.

1. Pre-authorised emergency scope. The customer signs, in advance, a narrow grant covering defined emergency scenarios — with a short duration, a restricted scope, and mandatory notification. The customer still authorised it; they simply did so ahead of time.
2. Break-glass with two vendor signatures. Where no customer grant exists, access requires two named vendor individuals to sign, generates an immediate customer notification, and is treated as an incident requiring justification.

Neither prevents legitimate emergency work. Both make ungated access rare and visible rather than routine and invisible.

Questions a customer should ask their platform vendor

1. Can your staff access my tenant data without an action by someone at my organisation? If yes, under what process?
2. Do I receive a record of every support access, and is it delivered to me rather than available on request?
3. What diagnostic artefacts do you ask me to upload, and what live credentials do they typically contain?
4. If your support system were compromised, what would an attacker hold that grants access to my tenant?

The fourth question is the one that gets an uncomfortable answer, and it is the one worth asking first.

The broader point

An identity platform is a concentration of authority by construction. That is its value and also its risk profile.

A customer who cannot see or gate the vendor's path into their tenant has not reduced their identity risk; they have moved it to an organisation whose controls they cannot inspect. The remedy is not distrust of vendors. It is designing the access path so that the customer holds the key to it.

What happened at Okta, and why it generalises

Okta disclosed that from 28 September to 17 October 2023 a threat actor accessed files in its customer support case management system belonging to 134 customers, under one per cent of its base. Session tokens embedded in uploaded HAR files were then used to hijack live sessions at five of those customers. Okta detected the breach on 13 October and disclosed publicly on 19 October.

Nothing in that sequence is specific to Okta. Every support organisation asks customers for diagnostic captures, and a HAR file is a faithful recording of authenticated traffic. The vendor ends up holding a pile of live credentials it never intended to collect, gathered through a workflow both sides consider routine.

Objections and honest limits

“We redact before upload.” Redaction helps and is incomplete by nature. Token formats change, custom headers are missed, and the person uploading usually cannot tell what is in the file. Treat redaction as reducing exposure, not removing it.

“Support access is contractual, so it is fine.” A contract allocates liability. It does not tell you when access happened, or let you gate it. Those are different properties and a customer usually wants both.

What a customer-signed grant does not fix: a vendor whose own infrastructure is compromised in a way that bypasses the impersonation path entirely, or data the vendor legitimately holds outside your tenant. It closes the gated path and leaves the rest to the vendor's controls.

Reducing diagnostic-upload exposure

1. Capture in an isolated session. Reproduce the issue in a private window with a throwaway account rather than an administrator's live session.
2. Strip and then verify. Run the redaction tool, then grep the file for Cookie, Authorization and your own token prefixes before it leaves your network.
3. Revoke immediately after. Treat any session used to produce a capture as burned, and invalidate it once the file is sent.
4. Ask what the vendor retains. Get the retention period for support attachments in writing, and whether they are encrypted at rest separately from case metadata.

Terms used here

HAR file

HTTP Archive: a JSON recording of a browser session including every request, response, header and cookie. Standard support diagnostic, and a faithful copy of live credentials.

Cross-tenant impersonation

Using access obtained in one tenant, or in the vendor's own systems, to act inside a different customer's environment.

Standing authority

Permission granted once, at role assignment, that persists until revoked — as opposed to authority granted per use and bounded in scope and time.

Frequently asked questions

Isn't support access necessary? Yes. The argument is about who authorises each use of it, not whether the capability should exist.

What about 2am emergencies? Pre-authorised emergency scope signed in advance by the customer, or break-glass requiring two named vendor signatures with immediate notification. Both keep the path open and make it visible.

Why are diagnostic uploads a problem? Browser session captures and debug bundles routinely contain live tokens and authorization headers. A support system holding many of them is a higher-value target than most individual tenants.

Can redaction solve it? It helps and is rarely complete. Custom headers and changing token formats get missed, and the uploading customer usually cannot tell what is in the file.

How many customers were affected by the Okta support breach? Okta reported that files belonging to 134 customers were accessed, and that session tokens from those files were used to hijack live sessions at five of them.

Why is a HAR file dangerous? It records every header and cookie in an authenticated browser session. A capture taken while logged in contains a working session token, and redaction tooling routinely misses custom headers.

Can we simply refuse to send diagnostics? Usually not, if you want the ticket resolved. Capture in an isolated session with a throwaway account, verify the redaction yourself, and revoke that session afterwards.

Sources and further reading

• FTC — business guidance on marketplaces and consumer protection
• HAR 1.2 specification — captured headers, cookies and content
• Cloud Security Alliance — Cloud Controls Matrix
• Okta Security — root cause and remediation for the support case management system incident
• BleepingComputer — 134 customers exposed in the October support system hack