- Enrollment and authentication-methods report from the identity provider
- The account populations, defined and counted (admins, remote users, general workforce, service exceptions)
- Sign-in logs showing legacy-protocol authentication attempts for the last 30 days
ATL-015TRACKEREDITORIAL REVIEW COMPLETE
MFA Deployment Tracker
A population-by-population rollout tracker for multi-factor authentication: totals, phishing-resistant versus other enrollment, enforcement status, dated-and-owned exceptions, and the legacy-authentication blocking checklist that closes the back door MFA leaves open.
Using this artifact
Purpose, inputs, and completion
Purpose. MFA rollouts fail in the gap between 'we bought it' and 'every account is enforced' — a gap that can quietly last for years. This tracker measures that gap weekly, population by population, separating phishing-resistant enrollment from weaker methods and enforced populations from report-only ones. It also carries the legacy-authentication checklist, because an enforced front door with an open IMAP back door is a rollout in name only.
When to use it. Define the populations, take a baseline count from the identity provider, and update one row set per week from the provider's enrollment report. Move each population to enforced when its not-enrolled count reaches the exceptions list and nothing else; then keep tracking monthly for drift. Every exception must carry a date, an owner, and an expiry — review them at each update and let none renew silently.
- Define the populations before counting anything, and start enforcement with administrators and remote access — the highest-risk accounts take the strongest method first.
- Update the tracker weekly from the identity provider's own report, not from the project plan; the plan says what should be enrolled, the report says what is.
- Distinguish phishing-resistant enrollment from other MFA in separate columns — a six-digit code stops password reuse but not a live phishing proxy, and the difference is the point of the campaign.
- Date and own every exception, with an expiry; an exceptions cell that says 'a few kiosk accounts' is where enforcement quietly dies.
- Work the legacy-authentication checklist in parallel: MFA on the front door means little while IMAP or basic authentication answers at the back.
Keeping it honest
Evidence, validation, and failure modes
- A dated weekly enrollment trend per population, from the identity provider's own reporting
- An enforcement record showing when each population moved from report-only to enforced
- A dated, owned exception register with expiries — and the legacy-auth blocking record
- Attempt a legacy-protocol sign-in (e.g., IMAP with username and password) against a test account; if it authenticates, the blocking checklist is not done regardless of what the policy screen says.
- Cross-check the admin population row against the privileged account inventory; every privileged account must appear in an enforced population or in the exception register with an expiry.
What looks done but is not
- Enrollment is tracked but enforcement never turns on — users have registered a method that sign-in never actually demands.
- Legacy protocols stay open for one aging copier or scanner, and that allowance quietly exempts every mailbox on the domain.
- Exceptions accumulate without expiry dates until the exception list is a second, unofficial population with no MFA at all.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain weekly snapshots through the rollout and monthly snapshots for a year after; the enrollment trend line is the cleanest evidence the deployment happened and held.
Full document
Preview — exactly what prints
TRACKER · IDENTITY & ACCESSv1.0 · REVIEWED 2026-08-06
MFA Deployment Tracker
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
MFA rollouts fail in the gap between 'we bought it' and 'every account is enforced' — a gap that can quietly last for years. This tracker measures that gap weekly, population by population, separating phishing-resistant enrollment from weaker methods and enforced populations from report-only ones. It also carries the legacy-authentication checklist, because an enforced front door with an open IMAP back door is a rollout in name only.
How to use it
Define the populations, take a baseline count from the identity provider, and update one row set per week from the provider's enrollment report. Move each population to enforced when its not-enrolled count reaches the exceptions list and nothing else; then keep tracking monthly for drift. Every exception must carry a date, an owner, and an expiry — review them at each update and let none renew silently.
Tracking cadence and method
Same source, same day each week — a tracker fed from mixed sources on random days produces trend lines that mean nothing.
Method
| Update day and owner | Identity provider report used (name / path) | Populations defined (and where each is documented) | Definition of 'phishing-resistant' used here (e.g., security key, platform passkey) |
|---|---|---|---|
Order of attack: administrators first, remote access second, general workforce third, service and shared-account exceptions handled explicitly last. Each population moves report-only → partial enforcement → enforced, and the tracker records the date of each transition.
Enrollment and enforcement tracker
One row per population per weekly update. Keep prior weeks' rows — the trend is the deliverable.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Population | Total accounts | Enrolled — phishing-resistant | Enrolled — other MFA | Not enrolled | Enforcement on? | Exceptions (dated, owned) | Target date |
|---|---|---|---|---|---|---|---|
| EXAMPLE: Administrators | 6 | 6 | 0 | 0 | Yes — enforced 2026-06-14 | None | Complete |
| EXAMPLE: Remote / VPN users | 23 | 11 | 9 | 3 | Report-only until 2026-09-01 | 2 shop kiosks — shared sign-in; owner IT leader, granted 2026-07-20, expires 2026-10-31 | 2026-09-01 |
Legacy authentication blocking checklist
Legacy protocols authenticate with only a password, bypassing every MFA prompt. Blocking them is part of the MFA rollout, not a separate project.
Closing the back door
Complete in order; record the date beside each item as it is done.
- Inventory legacy protocols in use: review 30 days of sign-in logs for IMAP, POP, SMTP basic auth, legacy device authentication, and anything labeled 'other clients'.
- Identify the legitimate dependents — the copier that scans to email, the line-of-business app with a hardcoded mailbox — and plan a modern-auth or app-password replacement for each.
- Enable blocking in report-only mode and watch the logs for a week; every blocked-would-be sign-in is either an attack or a dependency you missed.
- Enforce the block tenant-wide, with any surviving per-protocol exception scoped to the single account that needs it, dated, owned, and given an expiry.
- Re-check monthly: new legacy sign-in attempts in the logs mean either an attack in progress or a new device someone set up the old way.
Exception register
Every account outside enforcement, in one place, with an expiry. The register shrinks or the rollout is not finished.
Exceptions
| Account / population | Reason and compensating measure | Owner | Granted date | Expires |
|---|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Identity admin |
| Approval authority | IT leader |
| Review frequency | Weekly during rollout; monthly once every population is enforced, to catch enrollment drift and expired exceptions |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain weekly snapshots through the rollout and monthly snapshots for a year after; the enrollment trend line is the cleanest evidence the deployment happened and held. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.