Sharing passkeys: security doesn’t have to break collaboration.

The marketing team needs to publish a campaign, but the person who normally signs in is away. The credential is tied to their phone, someone is waiting for a code, and a security improvement has become a work stoppage. That is a workflow worth fixing rather than a reason to abandon stronger sign-ins.

A passkey saved in 1Password can be part of a shared Login item in an appropriate shared vault. That creates a way for authorized team members to use the credential through their own 1Password access. The goal is controlled collaboration, with a clear decision about who should be able to sign in.

What 1Password supports

On supported websites, 1Password can save a passkey in a Login item and use it to sign in. Its documentation also confirms that saved passkeys can be shared. This is different from assuming a credential stored only on a particular security key or personal device can simply be copied to the rest of the team. Check where the passkey is created and saved.

Source: 1Password, saving and using passkeys

In 1Password Business, custom groups can organize people by department or project and grant access to selected vaults. For example, a Marketing group could receive access to a vault containing approved team credentials. Each person should use their own 1Password account. Do not solve a shared-login problem by sharing the account that protects every other login.

Source: 1Password Business groups and vault access

Use the website’s own team roles when they are available

Start by checking the application’s native business access. Individual accounts, delegated roles, or a business manager can provide clearer permissions and accountability than several people using one shared service account. A shared passkey is useful when the shared credential is appropriate, not a reason to ignore a better supported team-access model.

Marketing often needs a workable handoff between internal staff, leadership, and outside help. Choose the access model with that handoff in mind. Some contributors may need publishing rights while others only need to review. Use the narrowest access that supports the actual responsibility, and follow the service’s account-sharing rules.

Set up the shared workflow deliberately

• Confirm that the service supports passkeys and that the team’s devices and browsers work with the chosen setup.
• Create or save the intended passkey in the approved 1Password Login item and vault.
• Assign the appropriate group or people and review their vault permissions.
• Test with a second authorized person before relying on the arrangement for a deadline.
• Document who administers the service account, its recovery methods, and future access changes.

Keep business credentials out of an employee’s private vault when the business needs to manage them. Separate internal and agency access where possible. Review permissions granted directly as well as through groups, since overlapping grants can affect the access someone retains.

Plan the exit as carefully as the handoff

Removing someone from a vault is not the same as revoking every session or credential at the website. When a person leaves or should no longer have access, review the service account itself: active sessions, registered passkeys, recovery details, passwords, and other sign-in methods. Remove credentials at the service when needed. Deleting a saved passkey from 1Password alone does not unregister it there.

RIKR includes a managed 1Password account in the cybersecurity offering. We see a practical benefit when stronger authentication no longer depends on finding one person who happens to be holding the phone. We can help choose and administer the workflow, including the plan features and application limits that apply to your team.

Related: why RIKR chose 1Password for business

Related: employee access control and least privilege

Explore RIKR managed cybersecurity