Introducing a team password manager: Clarify personal and shared accounts

A business wants to introduce a password manager for its team. Your IT services business can turn this into a specific project if the accounts genuinely needed jointly are identified before choosing the tool. A personal user account and a service account used by several people create different tasks. The customer needs a clear decision about what should be transferred, who confirms its use and which previous working practices will change.

Begin with the reason. Perhaps people repeatedly search for access during holiday cover, or management wants existing credentials in different places handled in an organised way. Record these situations without having passwords sent to your sales team. An initial quotation needs descriptions of services, responsible people and intended cooperation. Subsequent technical processing belongs in an explicitly agreed professional procedure.

Explain the problem through recurring work

Ask your contact about a specific task. Who processes a recurring order through an external service, for example, and what happens when that person is absent? The answer may reveal whether several people need the same service or whether a personal account is mistakenly treated as a shared solution. Your first task is to describe this starting point clearly. Wanting a password manager does not decide which existing account use should remain unchanged.

Ask what result the project should deliver. Should one department be able to use a new tool, should existing repositories be transferred, or does the customer first want shared accounts assessed? These services can belong together but have different completion points. Describe the initial scope sought. The customer can commission an actual introduction rather than expecting clean-up, setup and ongoing support under a product name.

Record the boundaries of the first area as well. A small purchasing team may provide a manageable starting point while other departments use different services. Selecting an initial area says nothing about its security. It defines which cooperation is considered first and who can provide information. Other teams are included later according to their own needs; belonging to the same company does not already put them in the confirmed scope.

Describe accounts without collecting secrets

An overview without password values initially suffices for quotation preparation. Which service is used, for what business purpose, and who is responsible? Ask the customer to identify known personal and shared accounts. Uncertain allocations remain open. A general employee list does not answer these questions because one person may have several different accounts for different tasks.

Mark whether information comes from the contact or still requires professional verification. The customer may assume that a service supports only one shared account. Your team assesses this prerequisite against the actual product and agreement within the agreed scope. Until then, it is an assumption. Marking it prevents a previous habit from becoming an immutable technical limitation during quotation preparation.

If credentials are needed for later work, your technical team clarifies the secure process and required authorisation. They do not belong in a freely forwarded quotation or general meeting note. Sales can explain which task must be prepared later. It does not need a collection of real passwords to advise on project scope and the responsible participants.

Distinguish a shared task from a shared password

Several people can work on the same task without necessarily sharing a password. The University of Stuttgart’s guidance on shared passwords recommends checking individual access options first. This gives your project a specific question for each service: Which actually available account and role options suit the cooperation needed? The university’s rules for personal university accounts do not thereby become blanket requirements for your customer’s business.

Explain the difference through the customer’s task. Several people processing orders initially represents a shared business need. Whether the service provides personal accounts with suitable permissions is examined separately. Your quotation can include that examination if your business actually offers it. A password manager is not sold as a replacement for every possible account decision.

If a shared account remains in scope after assessment, its users are deliberately defined. Ask about the task rather than blanket access for everyone. Accounting may need something different from purchasing even when both use the same platform. Your team assesses the possible technical implementation in the selected tool. The conversation confirms business scope rather than a particular product setting.

Separate personal areas and team access in the quotation

Clarify which information the customer regards as individual work accounts and which as agreed team accounts. Technical design depends on the product actually offered. Do not state without checking that every desired separation exists automatically. Your team must be able to show which confirmed function supports each need. An unresolved product question becomes a checking task rather than a promise derived from a general tool category.

Distinguish use from administration too. Someone needing access for a task should not need to manage all organisational settings merely for that reason. Ask who will administer the tool within the customer’s business and what support your company will provide. This responsibility belongs in project planning. The customer can see whether they are choosing introduction followed by their own administration or an additional agreed service.

Include outside participants deliberately. An existing IT partner can help prepare without automatically becoming a user of all team accounts. Ask which specific task requires their participation. Agree the professional and technical handling with the responsible parties. A name on a contact list is insufficient grounds for a broader access decision, and the quotation should make that boundary understandable.

Prepare transfer from existing repositories

Ask what kinds of repositories are currently used without copying their contents into sales records. There may be several lists or different personal tools. Your specialists determine which will be assessed and transferred within confirmed scope. If the customer expects a complete transfer, the known sources covered by that statement must be clear. The word complete does not automatically include an unknown additional repository.

Agree how duplicate or conflicting allocations will be resolved. Two entries for the same service may mean different accounts; identical names do not prove identical functions. Have the responsible customer contact confirm the business allocation and pass technical questions to the specialist. This distinguishes a transfer from unchecked copying and combining. The result should represent the accounts actually agreed in a traceable way.

Define how changes between preparation and transfer will be managed. If employees add new services meanwhile, that change needs a named route into the project. Your quotation can describe an agreed transition without demanding a blanket business interruption. The customer should know which version is considered and who supplies new information before it is missing elsewhere again.

Include further sign-in steps and recovery

The overview should also show whether the selected service requires additional sign-in steps. Germany’s BSI identifies two-factor authentication as additional protection where offered. For your preparation, this leads to a practical question: How will authorised cover use the actual intended sign-in procedure? Transferring a password entry does not answer that alone. Have specialists assess the solution without collecting second factors or recovery information in sales. The customer sees which extra coordination belongs to the desired cover arrangement.

Discuss what happens if the person responsible for administration is unavailable. Which confirmed deputy should take over which task? Your team assesses the provisions of the tool actually offered and describes the agreed scope. Do not promise universal recovery access. If this clarification belongs in the introduction, give it its own result: The customer should know the designated contact and agreed next route. This replaces neither technical assessment nor an actual trial of a separately commissioned procedure.

Walk through introduction using harmless examples

Prepared demonstration data suits explaining the planned process. The team can learn the desired use without exposing actual passwords in a general meeting. Describe the demonstration your business really offers within project scope. A demonstration shows the intended workflow; it does not prove all real accounts have already been set up or transferred correctly.

Choose a recognisable situation: An authorised colleague covering someone should perform a named task. Which business decision precedes it, which actually offered function is explained, and how does the person report an outstanding question? The concrete sequence helps the customer distinguish tool operation from business authorisation. Technical setup and checking subsequently take place within their confirmed framework.

Ask who is responsible for future changes. Who reports a team change, who assesses the continuing need for access, and who implements an agreed change? Your project can describe this handover with the customer. Exact technical implementation remains tied to the offered product. A one-off introduction alone does not confirm continuous maintenance of every future personnel and service change.

Advise a fictional purchasing team before tool selection

An imaginary purchasing team uses several external services. During holidays, the responsible person is sometimes absent, so management wants a password manager. Your colleague first records tasks and known account types without secret values. For one service, it is unclear whether personal users with appropriate permissions are possible. That question is included in the offered preparation before shared use is described as the final solution.

Following assessment, the business decides in this example which accounts belong in the initial introduction. Your quotation identifies the actual tool scope, commissioned transfer and explanation offered to the team. Other departments initially remain outside. Existing IT support receives a clearly named technical coordination task; this does not imply general access to every business service.

At the results discussion, work through confirmed cases and outstanding points. One previously unknown service still lacks allocation to a responsible department. That point remains open with an assigned owner. The customer can distinguish the agreed start from a later addition. The example promises neither a particular security level nor automatically complete company-wide clean-up; it shows a specific choice about the scope actually commissioned.

Win new projects for your IT security offering

Through webRichtung’s IT security page, you can obtain new business enquiries. A password-manager project and its scope arise in your own consultation; no additional order filter is promised for it. Register your business, choose your area and check the current price in webRichtung Customer before placing a binding order.

Sources

University of Stuttgart, RUS-CERT: Recommendations on shared passwords, read on 25 October 2026. The recommendation to examine individual access options provides professional orientation. The project and quotation structure presented is an editorial recommendation; specific product properties and customer rules are checked separately.

BSI: Basic IT security tips explains the value of password managers and additional two-factor authentication where available.