Google Authenticator does the cryptographic work well. Each enrolled account picks up a TOTP secret, an enrolment timestamp, a recovery-code counter, and a boolean enrolment flag, all written to per-user meta. The user list screen carries a column that tells you whether a specific account has 2FA on, which is the right surface for one user and the wrong surface for asking whether the administrator role meets the policy threshold.

SleekView reads the same user meta keys the plugin maintains and joins them to wp_users. Each row carries the username, the role, the enrolment status, the enrolment date, the recovery-codes-used count, and the last-login timestamp. A row showing role Administrator and enrolment Inactive next to a last-login of yesterday gives the security lead exactly the picture the user list screen does not summarise on a Monday morning.

Saved filters earn their keep here. A view filtered to role equals Administrator and status equals Inactive becomes the policy-compliance check. A view filtered to recovery-codes-used greater than five isolates the accounts that have probably lost their device. The plugin keeps writing exactly what it always wrote; SleekView turns it into a real operational surface.

Google Authenticator is well scoped for what it owns: generating, storing, and verifying TOTP secrets per user. The hard part for security teams is not the cryptography but the operational view. Knowing the enrolment rate across roles, which administrators still need to enrol, and which accounts have burned through their recovery codes matters more on a Monday morning than the underlying algorithm.

None of those questions get answered from the per-user profile screen the plugin ships with, and the small 2FA column on the user list is honest but not aggregated. SleekView reads the same user meta keys and lays a real grid over them. Same secrets, same recovery-code counters, much better posture for the team relying on them.