Keys to the Building: A Credential Ownership Map for UK Teams

Shared credentials rarely survive because nobody cares about security. They survive because they solve a practical problem. A front desk needs cover at 8am when the regular receptionist is on leave. A field engineer needs to update a job sheet from a phone that is not theirs. A small marketing team needs to schedule posts while one colleague is away. In each case, a shared login feels like the shortest route to continuity.

The difficulty is that the same login also removes accountability. When a message is sent, a setting changed or a file deleted, the organisation cannot easily say who did it. When someone leaves, the password becomes a handover item that is easy to forget and hard to verify. Under UK GDPR, the accountability principle expects teams to be able to demonstrate appropriate controls. A shared password is not automatically unlawful, but it makes that demonstration harder.

The answer is not a sudden ban. It is a credential ownership map: a practical record of what exists, who uses it, why it exists and how it will be retired. For UK teams running social, cloud and communications tools, the work is usually smaller than feared, provided it is sequenced carefully.

The operational reason shared logins persist

Start by acknowledging the reason people created them. Front-desk workflows often depend on a single inbox or portal that several people must monitor. Field teams may work across shifts and shared devices. Small teams may not have formal identity management, so a shared password becomes the default form of delegation.

A credible migration therefore has to preserve the workflow, not just remove the credential. If a reception team loses access to a scheduling tool at 7am, the security gain will be undone by the operational disruption. The aim is to replace the shared secret with named access, delegated permissions or a role-based process that keeps the work moving.

Begin with a census, not a ban

Set aside one week for a credential census. Ask team leads to list every tool that uses a shared login, including social scheduling platforms, cloud admin consoles, phone-system portals, file-sharing accounts and supplier dashboards. Use a simple form with four fields: tool, business purpose, current users and what happens if access is unavailable for a day.

Cross-check the list against single sign-on application inventories, finance records for renewals, browser password managers on shared devices and any written runbooks. Do not frame the exercise as a hunt for culprits. People will conceal shared logins if they expect punishment. Frame it as an operational continuity review, because that is what it is.

Record each entry in a register with a named business owner. The owner does not have to be the most senior person. They do need to understand why the tool exists and what the team would do without it.

Sort access by pattern, not by tool

A long list of tools can look overwhelming. Group the entries by access pattern instead. Most shared logins fall into four categories:

• Individual recurring use: several people use the same login for their own work. These are usually the simplest to convert to named accounts.
• Shift-based shared use: a front desk or field team needs coverage across hours. These need delegated access, role-based permissions or a properly managed shared mailbox, not a shared password.
• Service or automation access: a scheduling tool, integration or reporting script uses a login. These belong in a credential vault with a documented owner, not in a staff password manager.
• Emergency access: a break-glass account for administration when normal access fails. This should be rare, controlled and tested.

This classification prevents a blanket rule that breaks legitimate workflows. It also gives the migration a sequence: individual accounts first, shift-based processes second, service accounts third, emergency access last.

Put a name against MFA

Multi-factor authentication is often the point where shared-login plans collapse. A shared account may be protected by one person's mobile phone, which means that person becomes an unofficial gatekeeper for the whole team. If they are on annual leave, the workflow stops.

For named accounts, each user should own their own MFA method. For service accounts, use a hardware token or authenticator held in a controlled location with a named custodian and a backup custodian. For break-glass access, document who can retrieve the credential, under what circumstances and how the retrieval is logged.

The register should record the MFA owner as a role, not just a person. When someone changes job, the role can be reassigned without a scramble.

Break-glass access should be boring

Emergency access attracts dramatic language, but the process should be dull and repeatable. Create a break-glass account only where a genuine operational need exists. Store its credentials in a sealed envelope or a password manager with dual control. Require two custodians for retrieval. Log every use, including the reason and the time.

Test the process at least quarterly. A break-glass account that has not been tested is a hope, not a control. The test should confirm that the credential works, that the custodians can retrieve it and that the access is recorded. Keep the result in the business continuity plan.

A cutover sequence for front desks and field teams

Choose one low-risk tool for a pilot. Create named accounts, assign permissions and schedule a short cutover window. Avoid Monday mornings, month-end and the working day after a bank holiday. For front-desk teams, replace the shared login with a shared mailbox or queue that staff access through their own accounts. For field teams, confirm that single sign-on works on mobile devices and that offline notes are available if connectivity drops.

After the cutover, keep the old credential disabled rather than deleted for a short period. Monitor the support queue for missed access. Update the runbook and tell suppliers which named contact now owns the account. Once the pilot is stable, repeat the sequence for the next tool.

Make handover a checklist, not a conversation

Named accounts only deliver their value if joiners, movers and leavers are handled consistently. Build a short checklist: suspend single sign-on, revoke active sessions, transfer file ownership, reassign social scheduling roles, update the credential register and confirm the break-glass custodians if the leaver held that role.

For internal moves, treat the change as a partial offboarding. Remove access that is no longer needed and record the new owner. This is especially important for communications tools, where a departing administrator may still hold recovery details for a social account or phone portal.

The 90-day test

Three months after migration, review the register. Count how many shared credentials remain, how many named accounts have MFA enabled and how long it takes to revoke access after a leaver is confirmed. Update the register monthly and review access quarterly.

The goal is not a perfect security posture. It is a calmer handover. When a colleague leaves or moves roles, the team should know which accounts they held, who now owns them and how emergency access works. That is a more useful measure of control than a password that everyone knows and nobody owns.