Several colleagues know the login. Everyone can do the work. Then an owner asks who changed a setting, who should receive a recovery message or whose access should end when a contractor leaves.
A shared credential makes those questions harder to answer from the account name alone. Start with one important application and find out whether its supported access model can identify each person. This is an ownership review, not a reason to lock everyone out without a transition plan.
Separate the work resource from the sign-in identity
A team may need the same inbox, folder or application. Ask whether staff can reach that resource through their own authorized accounts, with permissions appropriate to their work. Confirm the vendor's current features and license terms instead of assuming that separate access is available or included.
Microsoft 365 illustrates the distinction. Its shared-mailbox guidance says the shared mailbox is not intended for direct sign-in with its associated account; delegated access uses the person's own mailbox. That is a Microsoft-specific model, not a rule describing every business application.
Ask what the current records can actually show
Have the application owner and IT contact review the available audit information together. Can a record identify an individual, or only a shared account? Does it cover the action you care about? Who can access the records, and how long are they available under your configuration?
Do not assume that introducing named accounts will reconstruct old activity or make every event attributable. Record what was verified and what remains unknown. An illustrative “changed by reception” note is not evidence of which person performed an action.
Give recovery and administration an owner
Identify the authorized administrator, the business approver and an alternate contact. Ask who controls recovery routes and how access is reviewed when duties change. Keep passwords, recovery codes and authentication secrets out of the review note.
CISA's Cyber Essentials recommends account inventories, access based on need and least privilege, and procedures for changes in user status. These principles support asking the ownership questions; the checklist here is original practical guidance, not a certification standard.
If the vendor only offers a shared account
Document the limitation rather than quietly declaring it solved. Ask the vendor which team-access, administrative, recovery and activity-record options it supports. Have the authorized owner decide how to handle the exception and when to review it again.
Agree a transition before changing credentials, sessions or permissions. Confirm that authorized staff can still complete their work and that the recovery owner can help. Do not borrow a coworker's authentication code or disable a security control to make the handoff easier.
Use an access-ownership note
- Application and purpose: Which business task depends on the account?
- People and permissions: Who needs access, and what should each person be able to do?
- Supported model: Vendor evidence for named access, delegation or the documented limitation.
- Recovery and records: Responsible owner, approved recovery route and verified audit coverage.
- Next action: Approver, technical owner, continuity test and review date.
This is different from arranging shared-inbox coverage while a colleague is away: first establish how each person is authorized to access the work. If you need help organizing that review, discuss VFIX IT consulting and confirm the service scope before making changes.