SecOps
Understanding account access
The Access chapter brings together who holds accounts, what those accounts can do and what their providers recorded. It helps you investigate access that may be unnecessary or risky, while keeping missing evidence separate from a confirmed problem.
Accounts, people and privilege
An account belongs to a provider. A person can have several accounts. A privileged account has an administrative or similarly powerful role. An automated service identity is different from a person's account.
Google Workspace supplies the directory used to match people and active state. SecOps matches provider accounts by email and uses organisation People links where available. Check identity matching before deciding that an unmatched account belongs to someone outside your organisation.
Connect and check coverage
In Settings → Access log sources, select Google Workspace, GitHub, Bitwarden, Scaleway, OVHcloud or Tailscale. These sources are independent of the scanner sources used for vulnerability findings.
Some reads need additional grants. The screen explains when Google admin roles, GitHub deploy keys or OVHcloud API credentials have not been read. For example, GitHub's fine-grained token needs repository Administration read permission for deploy keys. Workspace admin-role reads need the delegated role-management read scope. A successful connection test alone does not establish complete coverage.
Provider behaviour differs:
| Provider | A useful limitation to remember |
|---|---|
| Google Workspace | Directory state and 2-step verification enrolment are separate from observed authentication methods |
| GitHub | Organisation audit logs require Enterprise Cloud; member sign-in time is not supplied here |
| Bitwarden | Vault-export evidence depends on clients reporting events; unreported activity can be absent |
| Scaleway | Key-use history is unavailable, so its keys are not judged unused |
| OVHcloud | Account MFA enabled state is not reported; observed sign-in methods can still be available |
| Tailscale | Sign-in and MFA evidence belongs to its identity provider, rather than a Tailscale sign-in timestamp here |
Needs attention
The upper part groups accounts or events by rule. These are prompts to check evidence, not proof that an account was compromised.
| Attention | What to investigate |
|---|---|
| MFA off | The provider explicitly reports multi-factor sign-in disabled |
| Leftover access | Access still held by someone inactive in Workspace |
| New admin | A recorded grant of privileged access |
| Long-lived key | A credential whose lifetime exceeds the configured limit, where applicable |
| Safeguard off | A recorded weakening of a protection |
| Sign-ins | Repeated failed or denied sign-ins, or a provider security warning |
| Repo opened | A repository made public, transferred out, or private forking enabled |
| Vault export | A reported vault-export event |
| No sign-in | No provider sign-in within the configured period, with enough evidence to judge |
| Idle privilege | No recorded privileged change within the configured period |
| Unused credential | No recorded credential use within the configured period, where use is reported |
| No Workspace person | A human account not matched to a directory person |
The suspicious-sign-in rule includes five failed or denied sign-ins for one provider account over seven days. It does not mean five failures across all of a person's providers combined.
GitHub's private-forking finding concerns enabling that capability. Its organisation audit log does not establish that a private repository was actually forked.
What MFA tells you
Multi-factor authentication, MFA, uses more than one factor, such as a password plus a security key. Two passwords are still the same kind of factor. Some methods resist phishing better than others; NIST's authentication guidance explains the distinction.
Read the displayed evidence carefully:
- Off means explicitly disabled, not simply missing data.
- Not reported means the provider did not supply that state.
- Set up describes configured methods, where reported.
- Used in the last 90 days describes methods observed on successful sign-ins for supported providers.
Workspace, Scaleway and OVHcloud can supply observed methods. GitHub can report SMS among configured methods. Bitwarden and Tailscale do not report a method here. SMS and email receive a weak-method label. An enabled flag alone does not establish that every sign-in used a phishing-resistant method.
Inactivity and credential windows
Defaults in Settings are 60 days without a sign-in, 90 without a privileged change, 90 without credential use and a maximum key lifetime of 12 calendar months. The day windows can be 7–730 days; the key limit can be 1–60 months.
Each provider's activity is evaluated separately. No privileged change does not prove no use: a person may have read data without making an administrative change. Event-based checks wait for enough retained history before making an inactivity judgement. A GitHub deploy key cannot expire and is exempt from the lifetime rule.
The audit trail and inventory
Below attention, switch between Audit trail, Access changes, Reviews and Who holds access. The audit trail has provider, category and expected-activity filters. Open an event to see its time in UTC, actor, target, IP address, outcome and provider details when available.
The inventory describes reported accounts and roles. Not reported, none held and never describe different evidence states; do not read them all as inactivity.
Expected activity
Marking an event expected creates a rule requiring an exact actor, with optional provider and exact action or action prefix. These are literal matches, not regular expressions. The narrowest rule is offered first; choose the rule you intend to apply.
The rule hides matching event-based attention while preserving the underlying audit records. Expected events are hidden from the trail by default; turn them on to inspect them. Review the rule in Settings or remove it to restore matching attention. A state finding such as MFA off has no event to mark expected.
For example, suppressing one known automation action is narrower than suppressing everything its actor does on every provider. Check that a rule does not hide unrelated activity.
What happens after investigation?
Make account, role, safeguard or credential changes in the owning provider, then let SecOps read the corrected state. SecOps's access view does not revoke access or rotate keys for you. Record the period and conclusions using Access reviews.