How should an enterprise software startup design support access to customer accounts?
Enterprise buyers ask who at your company can open their account. A good design lets the customer grant time-limited access, blocks risky actions, shows the agent a banner and logs every step.
Illustrative situation: a startup sells supplier-quality software to a packaging manufacturer with 1,200 employees. Procurement sends a security questionnaire, and one line holds up the deal: “Can your personnel access our data? Who approves it, for how long, and where do we see it?” The honest answer is awkward: any of the startup’s 6 support engineers can press “Log in as” on any account, and the customer’s admin sees nothing. The scene is invented. It shows a debugging shortcut that became a privileged access path nobody designed.
Humbleteam, a digital product design agency, publishes this guide. It covers access models, grants and time limits, what a support agent may do, the agent’s banner, what the customer’s admin sees and what a security reviewer asks, with an invented worked example. Sources are described as of November 11, 2026, and vendor behavior can change. This is general information, not legal or compliance advice.
What exactly are you designing?
Two different things go by the name “support access.” Notion keeps them as two separate settings: one lets support act as a specific person, the other lets support reach workspace data. Salesforce’s Login Access is the first kind, giving the support user the same rights as the person it logs in as. Okta’s setting is closer to the second: it grants Okta Support read-only admin access for 24 hours.
Acting as a person reproduces what that person sees, but every action looks like theirs unless you record the real actor. A separate support identity is easier to limit and log, yet it cannot reproduce a permission bug. Many products need both, each with its own grant.
Which access model fits your product?
| Model | How it works | Documented example | Fits when |
|---|---|---|---|
| No access | Support works from screenshots and logs | HubSpot lets a Super Admin turn employee access off, and support then cannot investigate | Regulated data, or a contract that forbids it |
| Customer-granted, time-boxed | A person or admin turns access on, and it ends by itself | Notion ends it after 28 days, Intercom after 14 days | Enterprise accounts, as the default |
| Always on, logged | Staff enter without asking | HubSpot’s default gives employees limited access to parts of the account | Self-serve plans, if customers can switch it off |
| Read-only | Staff can look but not change | Okta’s 24-hour read-only admin access | Most diagnosis |
| Break-glass | The vendor enters without a grant | Zendesk reserves the right to assume an agent role without notice in emergencies or suspected terms violations | Outages and abuse, written into the contract and logged |
Our suggestion: customer-granted, time-boxed and read-only by default, with write access as a second grant. Keep break-glass, publish when it applies and show every use in the customer’s log. Approval schemes carry exceptions too: Google’s staff may bypass Access Approvals for single-customer outage remediation and legal requests.
Who should grant access, and for how long?
Vendors put the switch in different hands. In Salesforce, the individual user grants Login Access, no one else can change or revoke it, and durations run from 1 day to 1 year. Zendesk gives it to admins: account assumption is off by default, and the menu runs from 1 day to 1 year or “Indefinitely.” Notion has both levels, and an Enterprise organization can set one policy that overrides each workspace’s choice. Google’s Access Approvals, sold as an add-on, works per request, with access lasting 5, 15 or 30 days.
We suggest two layers. The customer’s admin sets a policy of “never,” “ask each time” or “allow staff with a ticket,” and under “ask each time” the affected person or an admin approves each request. Offer 4 hours, 24 hours and 3 days, not “indefinitely,” which a reviewer will question first. Tie every grant to a ticket and show the end time in the customer’s time zone.
What may the agent see and do?
Salesforce documents the strictest rules we found. Its support users ask the customer to make production changes, cannot export data through the interface, hit confirmations on email, username and IP range changes, and cannot open the page that grants login access. HubSpot hides Sensitive Data property values from its employees, and Notion says support asks approval for each specific action before it looks at workspace data or runs a fix.
| Action | In a support session | Why |
|---|---|---|
| Change password, email, MFA or SSO settings | Blocked | Hands the account to someone else |
| Create, view or rotate API keys | Blocked | A key outlives the session |
| Export or bulk download | Blocked | Data leaves the product |
| Billing, plan or payment details | Blocked | Money and contract terms |
| Grant, extend or change support access | Blocked | Support cannot approve itself |
| Send email or messages as the user | Blocked | Recipients cannot tell who wrote |
| Edit or delete records | Only under a write grant | Some fixes need it |
Enforce the list on the server, not only by hiding buttons, and log each blocked attempt.
What should the agent’s banner say?
The agent needs to know at every moment whose account this is and when access ends. No vendor page we read shows its internal banner, so this copy is ours, with the invented names from the worked example below.
- Active, pinned to the top, cannot be dismissed: “Viewing as M. Haugen, Ostrevik Packaging. Read-only. Ends 09:40 UTC tomorrow. Ticket 48213. End session.”
- Blocked action: “Support sessions can’t export data. Ask the customer to run the export.”
- 15 minutes left: “Access ends in 15 minutes. Only the customer can extend it.”
- Ended: “Access ended at 09:40 UTC. Nothing after that time was saved.”
A distinct color and tab title keep a second tab from being mistaken for the agent’s own account.
What does the customer see?
The grant screen has five states. Off: “Tessaloom support can’t open your account.” Requested: “Support asks for read-only access for 24 hours for ticket 48213. Approve or decline.” Active: “Read-only access until Nov 12, 09:40 UTC. Revoke now.” Expired and revoked each name the time and the person.
For notices, Zendesk emails every admin when an admin turns account assumption on. Atlassian’s Statuspage creates a 24-hour access grant for one page and emails the person who contacted support and the account owner, plus an activity log entry. We suggest emailing all admins on every grant and telling the person whose identity support uses.
In the log, Intercom records 4 events: consent approved, consent revoked, impersonation session start and session end. Notion logs each time workspace access is given, changed or ends. Salesforce’s setup audit trail lists setup changes made with a user’s login, and Google’s Access Transparency logs actions Google staff take on user content. Record the grant, the start, each action, each blocked attempt and the end. The actor should read “J. Ortiz (Tessaloom support) as M. Haugen,” never M. Haugen alone. Our audit log guide covers the rest of the schema.
What happens when access ends mid-session?
Decide whether ending access ends the session. On HubSpot, turning employee access off stops new employees, but existing employees keep access for the next 24 hours. A reviewer will ask about a gap like that.
Our rules: revoking and expiry both end live sessions at the agent’s next request, and the agent sees the “ended” state, not a generic error. Unsaved work is discarded, never written under the customer’s name after the grant ends. An extension is a new request the customer approves.
What will a security reviewer ask?
In the AICPA’s Trust Services Criteria used for SOC 2, CC6.2 requires authorization before credentials are issued, and CC6.3 asks for least privilege and removal of access no longer required. The CSA’s Cloud Controls Matrix asks for privileged access granted for a time-limited period (IAM-10), customer participation in granting agreed high-risk privileged access (IAM-11) and logging that stays read-only even for privileged roles (IAM-12). Its questionnaire, the CAIQ, asks about the controls as yes or no questions.
| Question | Related criterion | Screen that answers it |
|---|---|---|
| Can your staff reach our data without our approval? | IAM-11 | Admin policy: never, ask each time, allowed with a ticket |
| How long does access last, and can we end it? | IAM-10, CC6.3 | Grant screen with end time and Revoke |
| What can your staff do once inside? | CC6.3 | Published blocked-action list |
| Which of your staff can use support access? | CC6.2 | Internal role list with a review date |
| Can your staff alter the record of their access? | IAM-12 | Read-only log, actor shown as “support as user” |
| When do you enter without a grant? | IAM-11 | Break-glass policy and its log entries |
Salesforce answers the fourth question in public: fewer than 6% of its active employees and partners can use Login Access, each after an approval. Put your answers on your trust center before a reviewer asks.
Illustrative worked example: Tessaloom and Ostrevik Packaging
Everything here is invented. Tessaloom is a fictional startup that sells supplier-quality software. Ostrevik Packaging is a fictional customer with 1,200 employees, and its admin has set the policy to “ask each time.”
A buyer, M. Haugen, reports 3 stuck purchase approvals. Support engineer J. Ortiz requests 24 hours of read-only access as M. Haugen on ticket 48213. M. Haugen approves at 09:40 UTC on November 11, and all 4 Ostrevik admins get an email. The grant would end at 09:40 UTC on November 12.
In a 52-minute session, J. Ortiz opens 28 records and finds an approval rule pointing at a deactivated manager. An attempt to export the rule list is blocked and logged. J. Ortiz writes the fix in the ticket, an Ostrevik admin changes the rule, and the approvals move. At 11:05 the admin revokes access, 22 hours and 35 minutes early.
The audit log holds 33 entries: 1 grant, 1 session start, 28 record views, 1 blocked export, 1 session end and 1 revocation. The 31 session entries name J. Ortiz acting as M. Haugen. The grant names M. Haugen, and the revocation names the admin.
Where do these defaults stop working?
Products that hold health, payment or legal data may need “no access” as the default, with a contract clause for each exception. Read-only still exposes personal data on screen. Some bugs only reproduce with write access, and then the customer’s approval matters more than speed. The durations, blocked list, banner copy and two-layer policy are our suggestions; no source we read gives a right number. We read vendor documentation and tested no product, and a detail missing from a vendor’s page does not prove the feature is missing.
What can you produce now?
- An access policy: the models you offer, the default and the break-glass rule.
- A grant spec: who approves, durations, notices and revocation.
- The blocked-action list, enforced on the server.
- Banner and grant-screen copy for every state.
- An audit event list with the real actor in every entry.
- Answers to the six reviewer questions, on your trust center.
