← FinOpsAid blog

Who can reach what, and who has no 2FA? Reading the Security & Governance page — FinOpsAid blog

Who can reach what, and who has no 2FA? Reading the Security & Governance page

2FA compliance, admin count, findings by severity, permission drift and repository access — what each number on the FinOpsAid Security page means and which way is good.

Security & Governance is the page where the direction rules invert most often. Almost everywhere else in FinOpsAid a rising number is a rising cost. Here, one tile wants to be at 100% and three want to be at zero.

It's in a cost tool for a practical reason: the same dormant account that shows up as a wasted seat on Licenses is an unattended credential with repository access. One list, two arguments — and the security argument is usually the one that gets the cleanup scheduled.

Conventions used below are in the grammar behind every number.

The KPI row

Tile What it counts Direction
2FA Compliance Percentage of members with two-factor authentication enabled. Higher is better. Explicitly flagged as an up-is-good metric. 100% is the only comfortable value.
Members Total org members. Neutral — the denominator.
Without 2FA Members with 2FA disabled. Icon turns amber when non-zero. Lower is better. Zero is the target.
Admins Members with org admin. Lower is better.
Findings Open governance findings. Lower is better.

Three of the five want to be zero, and one wants to be 100%. That's a different reading posture from every other page in the product.

Admins deserves a number in your head. There is no universally correct admin count, but there is a shape: it should be small, stable, and every name on it should be explainable. A growing admin list is the most common form of permission drift, because elevation is granted to unblock something urgent and is essentially never revoked afterwards.

Members without 2FA

Why 2FA state and admin role must be read together A member without two-factor authentication is an account-takeover risk. An admin without two-factor authentication is an organisation-takeover risk, because that single credential can change permissions, add collaborators and alter billing. Cross-referencing the two lists on this page identifies the highest-priority accounts. TWO LISTS ON ONE PAGE — THE INTERSECTION IS THE PRIORITY MEMBER, NO 2FA Account-takeover risk. Blast radius: their repos. Fix: enforce the org policy. ADMIN, NO 2FA Org-takeover risk. Blast radius: everything. Fix: today. DORMANT, NO 2FA Unattended credential. Nobody would notice a compromise. The Admins card shows a 2FA chip per admin. That column is the fastest audit on the page. The Developers page tints any row without 2FA red, so the same finding reaches whoever is reading cost. Cross-reference the idle-seat list too: dormant plus no 2FA is the account nobody is watching.
Scan the Admins card's 2FA column before anything else on this page. It's a handful of rows and it's the highest-consequence check available.

The Members without 2FA card lists up to twelve members with their role, each name linking to their developer page. Its subtitle changes depending on state: it shows the count of recent admin changes when there has been permission drift, or "Account-takeover risk" otherwise. The header chip is red with the count, or green reading "none".

An empty list reads "Everyone has 2FA 🎉", which is the intended state.

Admins

Every org admin with a green on or red off 2FA chip. Subtitle: "Elevated org access — keep this list tight."

Two questions per row, and neither takes long. Should this person still be an admin? And is their 2FA on? A red chip in this table is the most urgent item on the page.

Findings

Governance issues ranked by severity, showing subject and detail, up to ten:

Severity Chip Meaning
critical / high red Act now.
medium amber Schedule it.
low green Note it.

Findings are the page's catch-all — anything the warehouse detected that doesn't fit the specific cards above. Read the detail line, not just the subject; the subject names the object and the detail says what's wrong with it.

Repository access

The broadest card, one row per repository:

Column Meaning Direction
Repository Name, linking to a per-repo access breakdown and out to GitHub.
Collaborators Total people with access. Lower is better for a sensitive repo.
Admins People with admin on that repository. Lower is better.
Outside Outside collaborators — not org members. Rendered in the warning colour when non-zero. Lower is better.
Teams Team grants on the repository. Neutral — team grants are usually healthier than individual ones.

Outside is the column that's coloured for a reason. An outside collaborator is someone with access who isn't in your organisation — often a contractor whose engagement ended, and whose offboarding went through HR without touching GitHub. Scan this column first.

The Teams versus Collaborators ratio is the governance signal. Access granted through teams follows people automatically when they change roles; access granted to individuals doesn't and accumulates forever. A repository with many collaborators and no team grants is one nobody is managing.

Clicking a repository opens its detail: collaborators and team grants, each showing login, permission level, and source — whether access came directly or via a team. That source column is what turns "who has access" into "why do they have access", which is the question you actually need answered during an audit.

What people get wrong on this page

The 60-second read

Frequently asked questions

Which security finding should I act on first?

An organization admin without two-factor authentication. That single credential can change permissions, add collaborators and alter billing, so its blast radius is the whole organization. The Admins card shows a 2FA chip per admin, which makes it a few seconds to check.

What does the Outside column on repository access mean?

It counts outside collaborators, meaning people with repository access who are not members of your organization. It is rendered in the warning colour when non-zero because the common cause is a contractor whose engagement ended and whose offboarding never touched GitHub.

Why is a security page in a cost tool?

Because the dormant account showing up as a wasted seat and the unattended credential with live repository access are the same person. One list supports two arguments, and the security argument is usually the one that gets the cleanup scheduled.

Want your own access posture? Connect your GitHub org — read-only, no changes are ever made — or explore the demo first. Related: dormant GitHub seats cost and security. Next: how to read the Benchmarking page.