Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Unable to set up Teams Starter Pack
The President of our 4 person company, subscribed to the Teams Starter Pack and made me an admin. When I look at the Team (So far it's only the two of us), I can see his personal vault, but not his work vault, which is the opposite of what he intended. He has asked me to figure out what's wrong and I've tried looking but can't find a way to address this. HELP.
Domain Migration/Merge
I am not sure if there was an option, may of the settings became unavailable once 1P was connected to an IDP(Rippling). 1- We are rebranding and migrating from domain W to domain A, is there a way to rename users from user @ w.com to user @ a.org while keeping their access and accounts? 2-I've also seen a few users having both a.org and w.com accounts, is there a way to merge the two under a.org? 3-When a user is offboarded they may have passwords not saved in a shared vault, I would manually login as the user to access those. Is there an admin tool/function to transfer those vault items to their manager? Thanks!
op item get --format json returns CONCEALED field values without --reveal flag
Hi, We are using the 1Password CLI heavily in scripted and AI-agent workflows where command output is captured into logs. Today we discovered a behavior in op item get that surprised us, and we'd like to confirm whether it is intentional or a candidate for change. What we observed We ran the same item retrieval six different ways against a CONCEALED field on a test API Credential item we created specifically for this verification: | # | Command | Returned the secret value? | |---|---|---| | 1 | op read "op://<vault>/<test-item>/credential" | YES (as designed) | | 2 | op item get "<test-item>"` (default text format, no --reveal) | NO — output: credential: [use op item get ID --reveal to reveal]` | | 3 | op item get "<test-item>" --format json (no --reveal) | YES — JSON output included "value": "<plaintext>" for the CONCEALED field | | 4 | op item get "<test-item>" --fields credential (no --reveal) | NO — output: [use op item get ID --reveal to reveal] | | 5 | op item get "<test-item>" --fields credential --reveal | YES (as expected — --reveal was passed) | | 6 | op item get "<test-item>" --reveal | YES (as expected --reveal was passed) | The surprise is #3: --format json silently returned the plaintext value even though no --reveal flag was passed. The text format (#2 and #4) clearly conceals the value with the message [use op item get ID --reveal to reveal], which strongly implies that --reveal is required to see the value. JSON output behaves differently. Why this matters to us Many agent and scripting workflows use --format json for parseability. A developer or AI agent might reasonably: Read the documentation, see that --reveal is needed to expose secrets Write op item get <id> --format json expecting metadata only Pipe the output to a JSON parser Inadvertently leak the secret value into logs, conversation context, or downstream tools We discovered this in the context of investigating a credential-exposure incident where an AI agent was capturing tool output into conversation logs. We ran the test against a throwaway test credential to verify the behavior before drawing any conclusions. The text-format default was safe; the JSON format was not. Our questions Is --format json returning plaintext for CONCEALED fields without --reveal an intentional design choice? If yes, what is the rationale? The asymmetry between text and JSON output is what surprised us. If intentional, would you consider documenting it more prominently? The current op item get documentation does not (as far as we can tell) warn that JSON format bypasses the --reveal requirement that the text format implies. If unintentional, would you consider concealing values in JSON output too (e.g., omitting the value field for CONCEALED fields, or replacing it with a sentinel like `"value": "<concealed>") unless --reveal is explicitly passed? Secondary feedback (lower priority) op read always returns the value to stdout. This is documented and we understand it is the command's purpose. But for AI-agent contexts, it would be useful to have a --check or --exists mode that verifies a path resolves without fetching the value. (Workaround: `op item get` with the vault/item portion of the path resolves the existence question without exposing the value, as long as we don't use --format json — see issue above.) op item list` is correctly metadata-only. We tested this exhaustively and confirmed it does not return values. However, the metadata it returns (item names, IDs, vault names, edit timestamps) is sensitive reconnaissance data in agent contexts. Could you consider adding a --minimal or --counts-only mode that returns just count: N for the matched query without surfacing item names? This would let workflows verify that a credential exists in a given vault without enumerating the inventory. op run masking is excellent and we love it. The automatic <concealed by 1Password> replacement on stdout/stderr from wrapped subprocesses is the gold standard. We've made op run the canonical pattern for any subprocess that needs credentials in our workspace. The --no-masking flag is correctly an opt-in rather than the default. Thank you for the careful design here. What we are doing in the meantime We have updated our workspace policy and AI-agent rule files to: Treat op item get --format json as a value-leaking command, on par with --reveal Use op run --env-file=<file> as the default credential injection pattern Use op read --out-file <path> whenever a credential needs to land on disk, never piping op read to stdout Never use op item list or any enumeration command in tool-output-capturing contexts We would still very much like your guidance on item #3 specifically, JSON format silently returning concealed values is the behavior that most worries us, because it is the easiest one to get wrong by accident. ThanksVisit 1Password at MSP Summit 2026
Hi everyone, We're excited to be heading to MSP Summit 2026 in Las Vegas from April 13–16. If you're planning to attend, we'll be at booth MSP67 and would love to see you! We're happy to field questions about 1Password Enterprise Password Manager - MSP Edition, learn how we can help you support your clients' security needs, or whatever is on your mind in the world of cybersecurity.Non-Profit - do I sign us up for Biz Acct?
I am on the board for a medium size non-profit. We have 8 or so Board Members, and dozens of active volunteers. I need a solution for our shared passwords for about FOUR of us or 5 at most , and since I've been personally using 1Password for 10-15 years, I want to get us set up on 1Password. Now my understanding is with a Biz Acct, the assigned users (some of whom will eventually 'roll off' of their 'jobs') will be allowed to set up PERSONAL accts. Am I asking for a headache in managing this? or Can users get their free personal... then if 'severed' from the shared, they can JUST sign up for and pay for their Personal Acct? I was contemplating a different solution -- of going for the FAMILY plan. What are the Pro's and Con's of this? Cheaper. But am I losing any needed control? What about when ppl roll off/get added to a job? Maybe I run out of slots.. ANY advice is very very welcome! KathPassword expirations
I would like to know if it is possible to do the following on 1password business: Force users to periodically change their 1password account key. The other thing is to force or have a report of the elements of the users to know how old or when they changed their passwords from other logins or configured MFA to know if they are complying with the policies . Any idea? Thank you!Agency using 1Password Business – struggling with duplicate items across vaults
Hey all, We've been using 1Password Business for a while now and generally love it, but we're running into a real pain point with how vaults work when you need to share credentials across different groups. Some context on our setup - we're a boutique digital agency, so we deal with: Internal team members (some stuff shared with everyone, some only within departments) Contractors who should only see specific items they need Clients whom we invite as guests to collaborate on their project credentials The problem is that 1Password doesn't let you share a single item across multiple vaults. So if a hosting login needs to be accessible to the internal dev team, a contractor working on that project, AND the client - we end up duplicating that item into 3 separate vaults. Now multiply that across a bunch of clients and credentials and it gets messy fast. The worst part is when someone logs in and gets prompted to change a password. They update it in their vault, but the copies in the other vaults are now stale. There's no linking between them, no way to even flag that duplicates are outdated. You just find out the hard way when someone tries to log in, and it doesn't work. We've been doing it this way for a while and I feel like we're either missing something obvious about how 1Password is meant to be used in this kind of setup, or this is just a known limitation people work around somehow. Anyone running a similar setup (agency, MSP, consultancy) - how do you handle this? Is there a better vault/group structure we should be using? Or do people supplement 1Password with something else for the external sharing piece? Appreciate any input. We have the Business for early adopters, and unfortunately, we were also told that that plan does not come with a complimentary Family Plan 🤔.
1Password deployment on VDI / Citrix environments - best practices and support status?
Hi everyone, We're evaluating 1Password for our organization and need to deploy it in a Citrix Virtual Apps and Desktops environment. I've read through the deployment documentation, but I'd like to get some clarity on a few points from the community or 1Password team. Our scenario: Citrix Virtual Apps and Desktops (mix of persistent and non-persistent VDI) Windows Server-based session hosts User profiles managed via FSLogix / Citrix Profile Management Questions: Non-persistent VDI: What's the recommended approach for non-persistent/pooled desktops where the VM is reset after each session? Is it sufficient to persist the local data folder via FSLogix or Profile Management, or are there additional considerations? Multi-session hosts (RDSH): Is 1Password supported on multi-session Windows Server environments where multiple users share the same server? Are there any known limitations? Browser extension: Does the browser extension work reliably in VDI scenarios, especially when connecting to a locally installed 1Password app on the virtual desktop? Installer choice: The documentation mentions that MSIX is preferred over MSI. Are there specific VDI-related reasons for this recommendation beyond the passkey limitation? Any insights from organizations running 1Password in similar environments would be greatly appreciated. Thanks!User with 1000s of Devices
Hello, I have a question regarding how the 1Password integration with Linux terminals works. We’ve noticed that several employees have over 1,000 devices associated with their accounts in their linked account history, with the vast majority being Linux terminals. Is this expected behavior, or is it something we should be concerned about? Thank you for your insight.
