Stop a Bitwarden login appearing on the wrong subdomain

A password manager suggests credentials using saved website addresses. Bitwarden's default base-domain matching can be convenient when one service uses several subdomains, but it may show a sensitive login on a sibling host where you did not intend to use it. Host or Exact matching narrows the suggestion. The goal is to reduce accidental selection, not to assume matching alone proves a page is safe.

Before you start​

Identify the real login page and its complete hostname from an independent bookmark or the service's official documentation. Note whether the service legitimately redirects among several hosts. Work-managed vaults may have a fixed default policy.

Do it step by step​

1. Open the affected login item in Bitwarden and inspect every Website (URI) entry. Remove obsolete test domains and suspicious addresses rather than just changing the matching method.
2. Choose the item's URI-match setting. Host matches the hostname and optional port; Exact is stricter and can require the full saved URI. Start with Host if login pages vary by path, then use Exact where a single stable path matters.
3. Save the item and open the legitimate sign-in page yourself. Check whether Bitwarden offers the expected credential and that the account shown is the correct one.
4. Open a sibling subdomain that should not receive that suggestion and confirm it no longer appears. Do not type your password on a test page you do not control; you only need to inspect whether the manager offers the entry.
5. If the service has multiple genuine login hosts, add each exact trusted URI to the same item or separate items rather than widening every credential's global default.
6. Before filling anywhere, inspect the address bar for a near-match domain, unexpected port or scheme. If a site sent you through a link in an email, reopen it independently before entering a secret.

Check the result​

The correct site should still offer the login while the unwanted host no longer does. Record the legitimate hosts so a future site migration does not leave you locked into a broken autofill assumption.

If something goes wrong​

If autofill stops on the real site, compare the full URI, scheme, port and path with the item. Review an organization's matching policy or equivalent-domain rules before adding broad wildcard-like patterns.

Know the limit​

Autofill absence is a useful warning but not a fraud verdict; autofill presence is not an endorsement. Domain parsing, redirects and compromised legitimate sites can still mislead. Always verify the site itself before using a password. Bitwarden URI-match options