Most chat security is administration, not cryptography
Your vendor encrypts the transport and documents its posture; what actually goes wrong at most companies is closer to home — a shared login, an ex-employee who still has access, a credit card number pasted into a transcript. Those live in YOUR settings, and they are all fixable on day one.
One human, one account — always
A shared "support@" agent login feels convenient and destroys three things at once: accountability (who said this?), coaching (whose transcript is this?), and offboarding (you cannot revoke one person from a shared credential without locking out everyone). Per-agent accounts are the single highest-value security setting in the product. There is no legitimate exception.
Least privilege, by role
- Agents answer chats — they do not need billing, deployment settings, or account administration.
- Admins configure — and there should be more than one (bus factor) but not many (audit surface).
- Departments as boundaries: routing scopes not just workload but visibility — the seasonal helper answering shipping questions has no business in billing conversations.
Offboarding is a same-day ritual
The day someone leaves the team, their agent account is disabled — not "soon," not "at the end of the sprint." Put it on the same checklist as email and VPN. Chat access is customer-facing: a forgotten account is not just data exposure, it is someone able to speak AS your company. Quarterly, list every active agent login and name its human; any orphan gets disabled the same day too.
Keep secrets out of the transcript
Transcripts persist — that is their value and their risk. Set the team rule and put it in the canned library: never ask for full card numbers, passwords, or government IDs in chat; move those flows to the systems built for them (your payment page, your password reset). When a customer pastes one unprompted, the polite script is honest: "I've noted the last four digits and I'd recommend not sharing the full number in chat — let me take care of this another way." Your data-retention and deletion duties (GDPR requests, the delete-visitor flow) get lighter with every secret that never entered the record.
The same instinct applies to the secrets your installation holds rather than your transcripts. If you run your own installation, the signing key behind unsubscribe links is one worth setting explicitly rather than leaving on its fallback, for reasons set out in what stops someone unsubscribing your address for you.
Know your vendor's posture — from the source
Finally, read your chat vendor's actual trust documentation rather than assuming: transport encryption, data processing terms, permissions model, deletion paths, and deployment options. MyLiveChat's is published plainly on the trust & compliance page — including what is offered, what is not, and the self-hosted option for higher-control workloads. A vendor that states its boundaries honestly is telling you it knows where they are.
The access review nobody schedules
Access grows quietly. Someone covers chat over a holiday, a contractor helps during a launch, a
colleague from another team is added for a week, and none of it is ever reversed because removing
access is nobody's job. A year later the account list is a fair record of everyone who has ever worked
there.
Put a quarterly review in the calendar and make it boring: list every account, name the person,
confirm they still need it, confirm the role is still right. Fifteen minutes, four times a year,
removes the single most common way chat access becomes a genuine risk.
Pay particular attention to shared and generic accounts. Anything named for a function rather than
a person — support, info, the shop floor login — cannot be reviewed, cannot be offboarded
and destroys the accountability that makes your transcript history worth anything.
When a device goes missing
A lost or stolen laptop or phone is the scenario most small teams have never thought through, and
it is the one where minutes matter. Chat is a logged-in session with access to conversation history,
so treat it as you would email.
Have a short written sequence ready: change the person's password immediately, which invalidates
their sessions, confirm they are signed out everywhere, and check recent activity for anything that
happened after the device was lost. If any integration keys or API tokens were stored on that device,
rotate them too rather than assuming they were safe.
Write down who does this when the person affected is the administrator, and make sure at least two
people can perform it. A recovery plan that depends on the unavailable person is not a plan, and this
is the most common gap in small-team security.
What to measure
Track the gap between someone leaving and their access being removed. If that number is ever
measured in days, the offboarding ritual is not working, and it is the highest-value thing on this
page to fix.
Count how many active accounts you have versus how many people are actually rostered to answer
chat. A persistent gap is dormant access, which is exactly what an attacker looks for because nobody
notices its use.
Keep a note of when you last rotated integration credentials and when you last read the vendor's
security documentation. Both age silently, and both are the sort of thing a customer's security
questionnaire will eventually ask you to date.
Several of these capabilities are switched per site rather than globally; see feature flags in your live chat workspace for how the defaults and overrides interact.
Sign-in protection is one of the few controls here that needs no configuration at all. What ten failed sign-ins actually locks describes the limit your accounts already have, and how to read it when someone reports being shut out.
Two account-level details are worth knowing before you need them rather than during an incident: what the sign-in door does under repeated failures, and how long the links in our account emails stay valid. How long the links in your account emails last covers the second, including why an older verification email still works.
One thing your team will meet before any of this becomes a policy question: the verification code that appears on the sign-in page after a few failed attempts. Why the sign-in page starts asking for a code explains what triggers it and what clears it, which saves a support ticket most months.