Support should never ask a customer to share their password, and customers shouldn’t give one, even to a team they trust. A shared password lets whoever holds it act as the customer with no limit, no expiry and no record of who really did what. Safer options exist for every situation where “just send me your login” seems like the quick fix.
This guide is for SaaS teams. It covers why asking to share a password with support goes wrong, what security guidance says, and what to offer customers instead: a guided screen share, co-browsing, or an approved, time-limited way to log in as the customer. It ends with a short message you can paste into your help center or macros.
Why is it unsafe to share a password with support?
Sharing a password is unsafe because it hands over the customer’s whole identity, not just a view of the problem. Here is what goes wrong, in rough order of how often teams hit it.
- It breaks multi-factor authentication. If the account has MFA, the agent can’t sign in with the password alone. Someone has to read out a code, approve a push prompt, or turn MFA off “for now”. Each of those trains the customer into the behaviour attackers rely on.
- It doesn’t work with single sign-on, or it’s worse. A customer who signs in through their company’s identity provider would have to share their corporate password, which unlocks far more than your app.
- Every action looks like the customer’s. Your logs show the customer’s user ID. If the agent changes a setting or deletes a record, nothing distinguishes that from the customer doing it.
- There is no scope. The password grants everything the customer can do, including billing, user management and data exports. You can’t make it read-only.
- There is no expiry. The password keeps working until the customer changes it, which may be never.
- It spreads. The password now sits in a ticket, a chat transcript, an email thread, maybe a notification preview. Those systems have their own access lists and retention.
- It’s often reused. If the customer uses the same password elsewhere, your support channel now holds a key to other services too.
None of this requires bad intent. A careful agent in a well-run team still creates all of these problems the moment they type the customer’s password.
What security guidance says about sharing passwords
Security guidance treats authentication secrets as personal. NIST’s digital identity guidelines (SP 800-63B-4) (opens in a new tab) say subscribers are responsible for protecting their authentication secrets and not disclosing them to others, and give credential sharing as the example. The same document notes that its protections are designed against theft, not against a user willingly handing the secret over. Once a password is shared, the controls you built around it no longer apply.
The OWASP Authentication Cheat Sheet (opens in a new tab) makes a related point about third-party apps: letting another party store a user’s username and password is not considered safe, because it extends your attack surface to systems you don’t control. A support desk holding customer passwords is that other party. The same cheat sheet calls MFA the best defence against most password-related attacks, which is exactly the control a shared password tends to get around.
Large providers say the same thing to their own users. Microsoft’s account security guidance (opens in a new tab) tells people that Microsoft will never ask for their password in email. Gmail’s phishing help page (opens in a new tab) says Gmail won’t ever ask for personal information like a password over email. Customers who have learned that lesson will rightly hesitate when your support team asks. Customers who haven’t learned it are the ones most at risk.
Should I give support my password?
No. If a support agent asks for your password, offer a screen share instead, or ask how they can investigate without it. A legitimate team should have another way to help.
If you’ve already shared it:
- Change the password, and change it anywhere else you used the same one.
- Sign out other sessions from your account security settings, if the app offers that.
- Check that MFA is still on and that no new recovery email, phone number or device was added.
- Tell the support team you’ve changed it, so nobody tries the old one.
It’s worth putting these steps in your own help center too.
What should support do instead?
Support should use a method that shows the problem without handing over the customer’s identity. There are three practical options, and most teams use more than one.
Guided screen share
The customer shares their screen on a call and clicks through the problem while the agent watches and directs. Choose it when the issue depends on the customer’s device, browser or the exact steps they take, and the customer is available now. It needs nothing built, but it depends on the customer’s time, and the agent sees only what the customer chooses to show.
Co-browsing
Co-browsing is a shared view of the customer’s page in your web app, usually through a script in your app, where the agent can see, and sometimes point at or click in, the customer’s session with their permission. Choose it when you want a smoother live session than a video call, with masking of sensitive fields, and the customer is present.
Approved, time-limited “login as customer”
User impersonation, often called “login as customer” or “login as user”, gives a staff member a separate session in the customer’s account context without the customer’s password. The user impersonation explainer covers the basics. Choose it when the customer isn’t online, the bug depends on their data, permissions or configuration, or you need to test a hypothesis against the account’s current state. Done properly, the session is approved, limited in scope and time, and recorded against the staff member, not the customer.
Session replay is a fourth tool, for a different question: what happened in a past visit. When session replay isn’t enough explains where it stops.
Comparing password sharing with the alternatives
| Shared password | Guided screen share | Co-browsing | Approved login as customer | |
|---|---|---|---|---|
| Customer must be present | No | Yes | Yes | No |
| MFA and SSO stay intact | No | Yes | Yes | Yes, if your backend creates a separate session |
| Actions attributed to staff | No | Customer acts | Depends on tool | Yes, if both identities are recorded |
| Can be read-only | No | Customer controls | Often | Yes, with backend enforcement |
| Ends on its own | No | When the call ends | When the customer stops | Yes, with an expiry |
| Engineering work | None | None | Install and configure | Build or integrate |
The password column fails on almost every row. The other three trade off differently: screen share and co-browsing keep the customer in control but need their time, while impersonation removes the scheduling problem and puts the controls on your side. The terms in this table are defined in the user impersonation glossary.
What makes “login as customer” safe enough to offer?
A login-as-customer feature is only safer than a shared password if it adds the controls the password lacks. At a minimum:
- A separate session for the staff member, created by your backend, that never uses or resets the customer’s credentials and never marks their MFA as completed.
- Both identities recorded: who is acting and whose account they’re in.
- A reason and an approval before access starts.
- Read-only by default, enforced on the backend, not by hiding buttons.
- An expiry and a way to end access early that your app actually honours.
Some vendors also let the customer approve access. Microsoft’s Customer Lockbox (opens in a new tab), for example, asks a designated approver in the customer’s organization to approve or deny an engineer’s access request, and access is revoked when the requested duration ends. Whether your own customers need that step depends on your contracts and policies. The multi-tenant impersonation checklist walks through the rest.
A message you can send customers
Put a short statement in your help center, your ticket auto-reply and your agents’ macros. Adjust the bracketed parts so they match what your team really does:
We’ll never ask for your password. Nobody on our team needs it to help you, and nobody should ask for it by email, chat or phone. If someone does, it isn’t us. Please don’t reply, and let us know.
If we need to see the problem, we’ll ask you to share your screen, or a named member of our team will [request approved, time-limited access to your account]. That access is [read-only unless you agree otherwise], ends automatically, and is recorded against the person who used it. You can ask us who accessed your account and why.
Only promise what your process enforces. If you don’t yet have approvals or read-only access, leave those lines out until you do.
How Devora handles login as customer
Devora lets authorized staff open your app as a selected customer without asking for or sharing the customer’s password (opens in a new tab). A staff member requests access with a reason, scope and duration. An approver or admin in your organization reviews it. Your backend then creates a short-lived login for that customer, and the session shows a visible banner in your app. Read scope blocks write requests on the backend, and endpoints you mark as sensitive stay blocked in both read and write sessions, as the scope and security guide (opens in a new tab) describes. Sessions end when the agent ends them, an admin terminates them, or their time runs out, and the access history keeps who accessed which account and why.
Your app still owns authentication, issuing and revoking the impersonation credential, tenant authorization and its own audit events. Today, Devora’s approvals happen inside your organization. A step that sends the request to the customer after internal approval, with the session starting once the customer approves, is on the roadmap.
If your team still answers tickets with “can you send me your login?”, create a Devora account and try one staging session with a test customer.
Sources
- NIST: SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (opens in a new tab)
- OWASP: Authentication Cheat Sheet (opens in a new tab)
- Microsoft Support: How to help keep your Microsoft account secure (opens in a new tab)
- Gmail Help: Avoid and report phishing emails (opens in a new tab)
- Microsoft Learn: Customer Lockbox requests (opens in a new tab)
- Devora: Overview for teams (opens in a new tab)
- Devora: Scope and security (opens in a new tab)