The Google Authenticator plugin focuses on one thing: pairing a WordPress user with a TOTP secret and validating the six-digit code at login. The plugin writes a googleauthenticator_* family of usermeta keys covering secret presence, verification timestamps, and an optional recovery code. The default Users screen still shows username, role, email, and post count, none of which answer 'which administrators have actually paired an authenticator app yet'.

SleekView reads wp_users joined with the Google Authenticator usermeta keys and renders one row per user. Role, enrollment status, last verified timestamp, and recovery-code presence become columns. Filter to role equals administrator and enrollment equals false to see the compliance gap. Sort by last verified to see who is actually using their authenticator and who never logs in.

Enforcement, recovery flow, and the TOTP validation remain entirely the plugin's responsibility. SleekView only adds the cross-user roster surface so the security team has a queryable view instead of a CSV from wp_usermeta.

Google Authenticator for WordPress is a deliberately small plugin and its scope ends at TOTP pairing, validation, and recovery codes. That focus is a feature, but it leaves the cross-user audit question (which administrators are actually paired, and how many have a recovery code) on the security team's plate. The default Users screen does not surface any of the googleauthenticator_* meta keys, so the answer requires either WP-CLI scripts or per-user clicks.

SleekView reads the meta the plugin already writes, joins it onto wp_users, and renders the roster as one filterable workspace. Compliance reviews stop being CSV-and-spreadsheet exercises and become a saved view that opens with one click. The plugin keeps owning TOTP.

The security team gains a real roster, audit-ready exports, and a way to identify dormant or recovery-code-less accounts before an external review notices them.