/signin-triage

name: "1Password Sign-in Triage"
description: >
  Triage of 1Password sign-in attempts for one client account: pulling the
  sign-in feed over a window, grouping failures by user, category and country,
  separating password-guessing from MFA failures and firewall blocks, spotting
  successes from new countries after a run of failures, and deciding what is
  noise and what goes to the client. The sign-in feed is admin-gated in
  Conduit and read-only.
when_to_use: >-
  When an MSP needs to investigate failed or suspicious sign-ins to a client's 1Password
  account, or wants a periodic sign-in health check. Use when: 1password failed sign-in,
  1password brute force, 1password mfa failure, 1password suspicious login, 1password sign-in
  report, or password manager login alerts.

1Password Sign-in Triage

Overview

A 1Password account is a high-value target: one compromised member can expose every shared vault they can open. The sign-in attempts feed records every attempt with its outcome, so an MSP can spot password guessing, MFA fatigue, and sign-ins from places the client does not operate. This skill reads that feed and produces a triage list. It cannot lock accounts or change policy; those are console actions.

Tools used

| Tool | Purpose | Conduit tier | |---|---|---| | `1password_events_introspect` | Confirm the account and that the token has `signinattempts` | read | | `1password_signin_attempts_list` | The sign-in feed | admin | | `1password_users_list` | Resolve targets to users and their state | read | | `1password_audit_events_list` | Optional: what a suspicious session did next | admin |

The sign-in feed is admin-gated in Conduit. Without the admin tier, stop and say so.

Key fields

Each attempt carries a `category` (the outcome), a more specific `type`, the target user, the client app and the location (including country). 1Password documents categories such as `success`, `credentials_failed`, `mfa_failed`, `sso_failed`, `firewall_failed` and `modern_version_failed`. Group on the values the feed actually returns rather than assuming this list is complete.

| Pattern | Likely meaning | |---|---| | Many `credentials_failed` on one user, few countries | Forgotten password, or guessing from one source | | `credentials_failed` across many users from one country | Password spraying | | `mfa_failed` on a user who also has `success` on credentials | The password is known to someone; the second factor stopped them | | `firewall_failed` | The client's 1Password firewall rules blocked the attempt; the control worked | | `modern_version_failed` | An outdated 1Password app; a support issue, not a security one | | `success` from a country with no prior activity | Travel, VPN, or compromise; needs confirmation |

Workflow

1. **Introspect.** Call `1password_events_introspect`; confirm the account and that `signinattempts` is among the features. 2. **Pull the window.** Call `1password_signin_attempts_list` with `start_time` (default: 7 days ago for a routine check, 24 hours for an active alert) and `limit` 200. Page with `cursor` while `has_more` is true. 3. **Group.** Count by category, then by target user and country within each failure category. 4. **Baseline countries.** From the `success` attempts in the window, list each user's usual countries. A success outside that set is a finding; a failure outside it is context. 5. **Correlate.** For a user with `mfa_failed`, or failures followed by a success from a new country, pull `1password_audit_events_list` for the same period and look for actions by that user after the success (invites, vault sharing, group changes). 6. **Resolve users.** Check flagged users against `1password_users_list` to see whether they are `ACTIVE` or `SUSPENDED`. Attempts against a suspended user are someone trying an old account. 7. **Report.**

Report format

• **Verdict**: quiet, noisy-but-benign, or needs client contact.
• **Needs client contact**: successes from unexpected countries, `mfa_failed` on a known

password, spraying across users. Give user, times (in the client's time zone), country, client app and count.

• **Benign noise**: forgotten passwords, outdated apps, firewall blocks working as intended.
• **Console actions** (manual): ask the user to change their account password, review their

trusted devices, sign out sessions, tighten firewall rules or MFA policy.

• **Coverage**: window, events read, and whether paging was cut short.

Gotchas

• **One hour by default.** Without `start_time` the feed covers only the last hour.
• **No user filter.** The feed returns all users; filter locally and keep windows short on

large accounts.

• **Policy is not readable.** No tool returns whether MFA is enforced. Do not infer the

policy from the feed; recommend the client confirm it in the console.

• **Times are UTC.** Convert before comparing with the client's working hours.