Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Feature Request: Show Original Contributor of Items in Shared Family Vaults
Summary Please add a built-in way to display who originally created or contributed an item to a shared vault in 1Password Family. Problem In shared family vaults, it is currently not possible to see who an item originally belongs to once it has been shared. This makes it unclear who owns a specific account, even though the item is visible to everyone in the family. As a workaround, we manually add tags with the name of the person who created or contributed the item. This allows sorting and filtering by owner, but it is manual, error-prone, and easy to forget. Proposed Feature Display non-editable metadata such as: “Contributed by: Name” or “Original owner: Name” This information should remain visible in the item details after sharing or moving an item into a shared family vault. Benefit This makes it easy to understand who an account actually belongs to, even when it is shared for convenience. It improves clarity in family vaults, avoids confusion, and removes the need for manual tagging. Reference Apple Passwords already shows this information for shared items using labels like “Contributed by: Name”, which provides clear ownership at a glance.
Onboarding experience: too hard
I have used 1P for many years, and it suits my needs as a software engineer nearly perfectly. However I have suggested it to a number of friends, and done the work of getting two distinct types of user up to speed: my partner (1P Families), and as the IT manager at a smallish company (1P Business). I started both a year or more ago, and thought I would share my experiences. tl;dr After a year, people are still struggling to understand 1P, and are still failing to gain the core benefits such as reused passwords. The main challenge my users have faced is how to migrate from whatever they used before ... intentional or not. My partner uses a Mac and iPhone, and has home and work Google accounts. She doesn't really understand that Safari and Chrome are different things, but uses both at work and home. In both cases, she accepted the default password management features, with autofill in chrome, and various flavors of Apple password managers. At any given time, without reconfiguration, all of these PW managers are competing to manage a password, and the result is confusion, and inevitable password resets "just to get in". So, the user ends up with multiple possible passwords saved in multiple places: Google, Apple, and now 1P. The same has been an issue for my co-workers, who are also at varying levels of technical awareness. The first thing I did for my partner, mainly to make her feel confident, was to import all the passwords from Google and Apple PW managers. This turns out to have been a really bad idea, and also, it's really a great deal harder than it should be -- not very well documented, hard to find on the site, and some parts of it didn't seem to work. This is a terrible idea because Google, at least, saves a new password for any different URL it finds, so there can be multiples just for one site. I am not sure about the Apple version, but the result was that we had at least two, often many more saved passwords imported into 1P. Finally, unless these PW managers are turned off, they keep adding their confusion to the mix. Suggestion: build an importer that figures out how to actually migrate to 1P. There may not be APIs that allow this to be automated, but at least you could build a step-by-step process, and a checker that sees the status and warns users. Ideally the tool would merge (or offer to) sites at the same domain, would identify a suitable name for the 1P entry, would retain history (archive) of old logins, and would coach the user through confirming the result on computer and phone. Passkeys and MFA are both great when 1P gets them right. But I am still regularly assaulted with the option to use passkey with my Amazon account, as well as my AWS accounts. The MFA process is kind of klunky
Best practice for user terminations?
Hi 1Password Community! Long time lurker first time poster here. We've been using 1Password Business at our company for a little under 3 years and love it. Our team has been debating on how best to handle user terminations in the scope of 1Password. Currently all users are manually managed (we're not using SSO with AD or anything). Two goals for user terminations: Goal 1: restrict access so the terminated user cannot access their company 1Password data Goal 2: no loss of any shared 1Password data So far we've simply been disabling users' 1Password accounts when they leave the company, achieving Goal 1, and leaving their 1Password data intact to set the potential stage for Goal 2. We're thinking we might have to just spend some time setting up dummy accounts and learning/testing behaviors, but I thought I'd try to shortcut that process and ask you good folks of the community :) The questions we have are: If the user created a shared vault, how can we reappropriate ownership of that vault and its items to someone else? We don't want to lose the information/passwords in the shared vault. If the user was a member of a shared vault and submitted items to it, are those items "owned" by the vault, or are they still tied to the user? (More specifically, if we delete a user's account, will all their submissions to a shared vault also be deleted?) If the user didn't follow training and was saving data to their "Employee" vault instead of a correct vault location, what is the best way to access their account to get at this data? We do have access to the user's email and company phone after termination, so impersonation comes to mind, but we're not convinced that's the best option to use. Are there any other things we should be considering when terminating a user from our environment? Thanks for reading :)Feature Request: Optionally allow sharing recipients to edit/update entries
Hi I love 1Password, cannot live without it in my personal and professional life. But one thing I struggle with is helping my customers maintain a safety first demeanor when it comes to sharing secrets. With 1Password it is easy enough for me to share secrets with them securely, but the inverse is not true UNLESS they also have 1Password, or similar. [2025.10.09 - Update] After looking into WHY this doesn't exist I now understand the problem that allowing an external non vault member to write directly into my vault would break the security model as that external non vault member would need my keys to write into my vault. So instead it could be something like this You initiate a “Secret Request” from 1Password: It generates a unique, signed URL. Optionally, you can label it (“Please send me your API key for X”). The recipient (your customer): Opens that link in their browser. Enters their secret (password, API key, etc.). Their browser encrypts it locally with a one-time symmetric key before upload. The key is only embedded in the returned “Send” link that comes back to you. You receive the “return link”: You open it once, decrypt locally, and copy the secret into your own vault. Optionally, the link auto-expires after one view or a set time. 1Password’s servers never see plaintext, they just store encrypted blobs. Full disclaimer, some AI servant came up with the above summary after I was trying to figure out why it may not be secure to just have people write directly into my vault and what the alternatives were. [Original not so secure feature request below] The feature I am looking for and would be willing to pay for, would be to allow sharing an entry, blank or otherwise, and then to optionally indicate that the sharing recipient may update the values or create new ones. Basically I want to allow someone external to be able to populate an entry in my vault as a mechanism for them to securely share secrets with me. Use case: I need to do an integration project with my customer's ERP system and I need a secret from them. They need to share this secret with me and may not have a great way to do that securely. So if I could securely send them a link to an entry in my vault with edit permissions, then they could easily just drop the secret in there. From a feature point of view, I guess it doesn't have to be limited to Update only, you could send someone a "Please create a new entry in my vault request", and then the entry would not have to exist prior to them getting the create request. Let me know what you think
Misleading pricing to upgrade
I have 1Password on my iphone and in the update section there is a message about updating. The message states: " This is an older version. To use the new version of our app, first upgrade to 1Password membership, and you'll receive one year free. Then, migrate your 1Password data." When I went through the process and got to payment, it provides that I must pay the annual fee of USD36 after a 14 days' free trial. This is misleading and deceptive as the original message reads as if you receive 1 year free for the upgraded app before you start paying. This is very disappointing given that 1Password is meant to be about security and preventing scams. Can someone assist with explaining how to obtain the 1 year free upgrade as promised by 1Password in my current app, or am I misunderstanding something here?
Enhance Security Against Windows 11 Recall Feature
Dear 1Password, I am writing to express concerns regarding the privacy implications of the Windows 11 Recall feature, which automatically captures screenshots of user activities. As highlighted in Signal’s recent announcement (https://signal.org/blog/signal-doesnt-recall/), this feature raises significant risks for applications handling sensitive data, as it could inadvertently capture and store confidential information. Given that password managers store highly sensitive data, such as login credentials and personal details, I strongly urge you to implement robust safeguards to protect user data from being accessed or recorded by the Recall feature or similar technologies. Signal has temporarily adopted DRM technology to mitigate this issue, but I recommend exploring additional or more advanced measures, such as: 1.Preventing Screenshot Capture: Implement mechanisms to block or obfuscate screenshots taken by the Recall feature when your application is in use. 2.Encrypted Data Display: Ensure that sensitive data is displayed in an encrypted or masked format to prevent exposure in screenshots. 3.User Notifications: Provide clear alerts to users when the Recall feature is detected, advising them to disable it or take precautions. 4.Enhanced App Isolation: Use sandboxing or other isolation techniques to prevent external applications from accessing your app’s data. By proactively addressing this issue, you can enhance user trust and ensure that your password manager remains a secure solution for managing sensitive information. I hope you will consider these suggestions and share any plans to implement protective measures. Thank you for your attention to this critical matter. Sincerely, Din
Watchtower idea
So I go into Watchtower, and it's always pretty overwhelming—68 vulnerable passwords, 78 weak ones, etc. Trying to get this in better shape is daunting. So I do what most people do: close Watchtower and try not to think about it. But what if we could chip away at it in a way that didn't feel so overwhelming? What if every day, 1Password gave me one website from Watchtower to change my password on? It could priorities sites that are both vulnerable and have passkeys available, so it's only a couple clicks and users start seeing progress. Then it goes to vulnerable, and down the line of whatever is most important. In just a few weeks you'd start seeing your score improve which is relieving and motivating.
