← 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
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
- Applying cost-page direction rules. Here 2FA compliance wants to be high and three other tiles want to be zero.
- Reading the admin count without reading the names. The number isn't the finding; the list is.
- Ignoring the Outside column because it's small. One stale contractor is the whole finding.
- Treating findings as informational. They're ranked by severity because they're meant to be worked.
- Separating this from cost work. The dormant-seat list and the unattended-credential list are the same people.
The 60-second read
- 2FA Compliance: anything below 100% has a list behind it.
- Admins card, 2FA column — the highest-consequence check on the page.
- Findings, critical and high only.
- Repository access, Outside column, top to bottom.
- Cross-reference the idle-seat list from Licenses. Dormant plus no 2FA is where you start.
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.