Create intermediate Works with: Any AI

Multi-Factor Authentication Rollout Plan

Table output Has example

Introduce stronger sign-in without a revolt.

The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.

Rate this prompt

Loading ratings…

Plan an MFA rollout. Systems covered: [SYSTEMS]. User groups and their devices: [USERS_DEVICES]. Methods available (authenticator app, hardware key, SMS): [METHODS]. Support capacity: [SUPPORT_CAPACITY].

Create a phased plan: pilot with volunteers, administrators first, then wider groups, then enforcement date. For each phase give a goal, communications, training, support arrangements, success measures, and a rollback plan. Compare the methods on security, convenience, cost and recovery with a table, noting weaknesses of text-message codes without overstating them. Plan for lost devices, travellers, shared accounts, and people without smartphones. Provide announcement emails for week minus four and week minus one, and a short FAQ.

Add a support readiness checklist, including scripts for the helpdesk to handle the ten most common problems, and metrics to watch during the rollout such as enrolment percentage and support tickets per day. Include an exceptions procedure with an expiry date for users who cannot enrol immediately, and a note on protecting the recovery process.

Add a worked pilot plan: twenty volunteers across three roles, two weeks, five success measures (enrolment completed, sign-in failures per day, support minutes per user, number of lockouts, satisfaction on a five-point scale) and a go/no-go rule for widening. Provide the helpdesk script for the three most frequent problems (new phone, lost authenticator, travelling without signal) including how the helpdesk verifies identity without weakening the control. Add the text of the enforcement-day message and a plan for the first morning of enforcement, with extra support staff on call. Include a recovery design section: how backup codes are stored, who can reset a factor, and the delay and notification applied to any reset so that attackers cannot use the recovery path. Finish with a post-enforcement review at thirty days: enrolment rate, number of access exceptions still open, support tickets per user, and lessons for the next group.

Scope: my own organisation and accounts only. If a request drifts toward attacking others, refuse that part and offer the defensive alternative.

Fill in before use

Optional: type your details and the prompt above updates. Nothing is saved or sent.

Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.

See an example result (fictional data)
Phases: pilot (10 volunteers, 2 weeks), administrators (week 3), departments in waves (weeks 4-7), enforcement date (week 8).
Methods compared: authenticator app (secure, free, needs phone), hardware key (strong, cost), text codes (convenient but weaker).
Support readiness: scripts for lost phone, new phone, travel.
Exceptions: people without smartphones get a hardware key; shared accounts removed.
Metrics: enrolment percentage; tickets per day.
Announcement (week -4): "From 12 May all accounts need two steps. Here is how..."
Recovery process protected: verify identity by video call.

Illustrative only, made-up data. Your results will differ and must be reviewed.

Related prompts