vulkro-sf org login-history
Reports LoginHistory anomalies
(SF-LOGIN-HISTORY-001 / -002 / -003) plus the per-profile
login-policy audit (SF-LOGIN-POLICY-001 / -002 / -003: missing IP
allowlist, phishing-resistant or high-assurance MFA gap, and over-long
per-profile session timeout).
Two questions in one command: what logins actually happened recently, and what the org's profile-level login policy would have allowed.
Synopsis
vulkro-sf org login-history --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. |
--format <fmt> | enum | table | Output format. |
--verbose, -v | flag | off | Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins). |
What gets read
LoginHistory rows (UserId, LoginTime, SourceIp, Status,
Browser, Platform, Application, LoginType), most recent first,
capped at the latest 1000 rows. Alongside that, the set of
admin-tier user ids and the loginIpRanges (start and end address,
both inclusive) configured on admin-tier profiles.
What gets reported
LoginHistory anomalies
| Rule | Severity | What fires |
|---|---|---|
SF-LOGIN-HISTORY-001 | High | A successful admin login from an IP outside the trusted profile ranges. Signal login-history-admin-from-untrusted-ip. |
SF-LOGIN-HISTORY-002 | Medium | A failed-login burst: at least 5 failed rows attributed to one user within the 1000-row window. Signal login-history-failed-burst. |
SF-LOGIN-HISTORY-003 | Medium | An admin user logging in over the legacy SOAP / Application path. Signal login-history-admin-application-login. |
SF-LOGIN-HISTORY-001 fires only when at least one trusted IP range
exists. An org with no profile IP restrictions has no "untrusted"
baseline to compare against, so the rule stays quiet rather than
flagging every login. The missing-allowlist case is reported separately
by SF-LOGIN-POLICY-001.
Per-profile login policy
| Rule | Severity | What fires |
|---|---|---|
SF-LOGIN-POLICY-001 | Medium | A privileged profile with no IP allowlist. Signal login-policy-ip-allowlist-missing. |
SF-LOGIN-POLICY-002 | High | A privileged profile that does not require phishing-resistant / high-assurance MFA. Signal login-policy-phishing-resistant-mfa-missing. |
SF-LOGIN-POLICY-003 | Medium | A per-profile session timeout above the supported floor. Signal login-policy-session-timeout-too-long. |
Examples
vulkro-sf org login-history --target-org my-prod
vulkro-sf org login-history -o my-prod --format json > login-history.json
Exit codes
0- no findings.1- posture findings reported.2- error.
These follow the org command-family contract printed by
vulkro-sf org --help.
Scope and honesty
The org is read locally through your own authenticated sf CLI login;
nothing is sent anywhere. The audit reads login telemetry and profile
login policy. No business records are read.
Two limits worth stating plainly. First, the LoginHistory window is the latest 1000 rows: a busy org can push older activity out of the window, so absence of a finding is not evidence that nothing happened. Second, these are posture and anomaly signals, not confirmed intrusions. An admin login from an untrusted IP is very often a legitimate admin on a new network, and it is reported so a human can decide. Nothing here certifies that an org was not accessed.
Where to go next
- vulkro-sf org session - the sessions those logins created.
- vulkro-sf org mfa - live MFA enforcement.
- vulkro-sf org audit-trail - what was changed in Setup after those logins.