Access management
Retire shared logins with a named-owner migration plan
A step-by-step plan for moving work off shared credentials and onto named accounts without interrupting the people who depend on the mailbox, admin panel, or tool.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A shared login usually starts as a convenience for a small team and becomes a liability once several people depend on it. Nobody can say who changed the password, which mailbox rule was added, or who still has the credentials saved on a personal device. Retiring the shared account is not a single password reset. It is a migration with a named owner, a replacement account model, and a tested cutover that keeps the work moving while the old path closes.
Why shared logins persist
Shared credentials survive because they remove a small friction at the moment a team is busy. A single mailbox login lets three people answer customers without waiting for an administrator, and a shared tool password avoids a licence seat or a permission request. The arrangement feels efficient until someone leaves, a password leaks, or an audit asks who performed a specific action. At that point the team cannot reconstruct the answer from the account record, and the convenience turns into an investigation.
The cost is rarely visible in the monthly budget. It appears as a password reset that locks out the whole group, a forwarded message that cannot be traced, or a former contractor who still knows the login months after the contract ended. Managers often tolerate the risk because the fix looks expensive. A written migration plan turns that vague cost into a sequence of small, reviewable steps, each with a named owner and a clear end date.
Inventory every shared credential
Start with an inventory that lists each shared account, the people who use it, the systems it can reach, and the business process that depends on it. Check password managers, browser profiles, and saved sessions as well as the official credential store. Ask each team to name the logins they actually use rather than the ones listed in a policy. The inventory will usually include at least one account that nobody remembered, and that account is often the one with the weakest controls.
For each entry, record the owner who can authorize a change and the last time the password was rotated. Note any recovery email, phone number, or backup code attached to the account, because those paths often stay with the original creator. Capture the integrations and scheduled jobs that sign in with the same credentials. Those dependencies determine the order of the migration and the tests that must pass before cutover, so do not treat them as a later detail.
Choose the replacement account model
Most shared logins should become either a role-based account with delegated access or a set of individual accounts with a shared mailbox or group. A role account works for a service that genuinely belongs to a team, such as a support inbox or a facilities calendar. Individual accounts with delegated permissions work better when the system records actions and the business needs to know who did what. Choose per use case rather than applying one rule to every login, because the audit value differs by system.
Write down how the replacement handles joining, leaving, and temporary cover. A new team member should gain access through the same request path as everyone else, and a departing member should lose it on the last day without a manual reminder. If temporary cover is common, define a time-bound delegation rather than sharing a password. The model is only finished when those three cases have a named owner and a documented approval step.
Migrate in a low-risk order
Sequence the work from the least disruptive account to the most critical one. Start with a tool that has a small user group and a clear rollback, then apply what you learn to the mailbox or finance system. Announce each cutover to the people who use the account, with the date, the new sign-in method, and the fallback if something fails. A quiet migration creates a queue of confused users and a temptation to keep the old login alive just in case.
Test the new account with the real tasks the team performs, not only a sign-in check. Send a message from the new mailbox, open a shared document, run a scheduled report, and confirm that notifications arrive at the right place. Keep the old account disabled but recoverable for a short, stated period. That window gives the team a safe way back without leaving an open door indefinitely, and it makes the final closure a deliberate decision.
Handle the exceptions honestly
Some systems cannot support individual accounts, and some vendor contracts require a single service login. Do not pretend those exceptions have been solved. Record the system, the reason, the compensating controls, and the date of the next review. A shared password in a managed vault with access logging is different from one written on a sticky note. The record should show which situation applies and who accepted the remaining risk.
Set a maximum life for each exception and name the person who must renew it. If the vendor adds single sign-on or role-based access, the exception should end rather than continue out of habit. Report the open exceptions to the manager at the same cadence as the access review. Exceptions that are visible and dated are manageable, while undocumented ones quietly become the real access policy for the company.
Prove the old path is closed
After the cutover, check that the old credentials no longer work and that no saved session or application still uses them. Review the sign-in logs for the old account, the forwarding rules, and any connected app that was authorized during the migration. Ask a user who was not involved in the project to try the normal workflow. Their experience is a better test than the migration team's checklist, because they will notice a missing permission or a confusing prompt.
Close the inventory entry with the date, the replacement, and the evidence that the old path failed safely. Keep that record with the system documentation so the next administrator does not recreate the shared login. Schedule a follow-up check after thirty days, when cached sessions and forgotten mobile apps tend to appear. A migration is complete when the old account is both disabled and unnecessary, not merely when the new one works.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the access, asset, and recovery practices discussed in this guide. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the shared login migration plan and the vendor contact directory guide before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what retire shared logins with a named-owner migration plan means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review