Run a registration campaign by prompting users to enrol a preferred authentication method, such as a passkey or Microsoft Authenticator, during sign-in or through a staged rollout. Target the right users first, communicate the deadline, and exclude emergency accounts. Track completion rates and failed enrolments, then tighten sign-in policy only after enough users have registered successfully.
What a registration campaign is doing in Entra ID
A registration campaign is an enrolment nudge, not a separate sign-in method. In microsoft entra id, it prompts selected users to add a preferred method such as passkeys or Microsoft Authenticator so you can raise phishing-resistant coverage before you enforce stricter sign-in controls. The campaign works best when you treat it as a measured rollout with clear user targeting, reminders, and an end-state policy change.
The key design choice is timing. If you push everyone at once, support volume spikes and users who are blocked from enrolment can slow the whole rollout. If you stage the campaign, you can start with groups that are easiest to convert, verify that the method works in your environment, and then expand to the rest of the workforce. The campaign should fit the method lifecycle, including recovery and exception handling, rather than being treated as a one-time admin toggle. See the Passwordless and Passkeys Guide for the rollout mechanics behind passkeys, and the Authenticator Apps and OTP Guide for enrolment details that still matter when users are being asked to add Microsoft Authenticator.
For passkeys, the campaign should reinforce that the user is registering a strong, phishing-resistant authenticator, not just another app. For Microsoft Authenticator, it should make clear whether the goal is push approval, number matching, or another supported mode, because those user experiences affect completion rates and help desk demand. If your campaign is part of a broader workforce rollout, the control point is usually the identity provider policy layer, where the registration prompt and the later sign-in requirements finally meet.
How to stage users, deadlines, and exceptions
Good campaigns are narrowly targeted. Start with users who can complete enrolment without needing special hardware, legacy device workarounds, or unusual recovery steps, then expand to broader populations once the flow is stable. A passkey campaign usually benefits from device and browser readiness checks, while a Microsoft Authenticator campaign needs a clean path for app installation, QR enrolment, and backup or recovery if the first enrolment fails. If the campaign has no clear deadline, users tend to defer it indefinitely.
Deadlines work only when paired with communication that explains why the change matters and what users should expect. The message should tell them what method is being requested, when they will start seeing the prompt, what to do if they cannot enrol, and where to get help. You should also exclude or separately handle emergency accounts and other break-glass identities, because their purpose is continuity, not interactive enrolment pressure. Keep those accounts tightly controlled and tested outside the campaign path.
When enrolment is staged, the operational question is not just who is prompted, but who is allowed to fail safely. That means defining exception paths for users with unsupported devices, travelling staff, or users who cannot complete the method registration on the first attempt. If you do not define that path up front, the campaign will create informal exceptions through the service desk instead of managed ones through policy.
What to monitor before you tighten policy
The campaign is successful only when registration is real, usable, and sufficiently widespread. Track completion rates by population, failed enrolments by reason, and help desk demand during the rollout. A high prompt count with low actual registration means the campaign is generating friction, not assurance. You also want to know whether the failures cluster around device type, browser, region, or a specific user segment, because that tells you whether the issue is configuration, communication, or user readiness.
Do not tighten sign-in policy the moment the first users register. The control only becomes useful when enough of the target population has adopted the method that the stricter policy will not strand large groups. In practice, that means watching for both adoption and successful sign-in use, not just the presence of an enrolled credential. If you are rolling out passkeys, the NIST SP 800-63 Digital Identity Guidelines are the clearest external reference for phishing-resistant authentication expectations and assurance thinking. For identity-side rollout and admin planning, the Workforce Identity Security Guide is a useful companion because it ties passkeys, MFA, recovery, and sign-in hardening together.
Risk and Threat Considerations
A registration campaign can fail in a way that looks like progress, especially if users click through prompts without finishing a usable enrolment or if the campaign pushes them into weak fallback methods. The security risk is not the campaign itself, but the gap between intended policy and actual authenticated state, which can leave a tenant believing it has stronger assurance than it really does.
Failure mechanism: Users who cannot enrol quickly may defer, choose the easiest fallback, or rely on help desk-driven recovery paths that are easier to social engineer. If emergency accounts are not excluded, their special handling can also create policy exceptions that undercut the rollout.
Impact: The organisation may end up with partial adoption, confused users, higher support load, and a false sense of readiness to enforce stronger sign-in requirements. In the worst case, stricter policy is turned on before enough users have a working method, creating lockouts and exception pressure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkey and Authenticator enrolment directly depend on phishing-resistant authenticator guidance. |
| Recommendation — Use the assurance guidance to align enrolment and enforcement with the intended authenticator strength. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Registration campaigns change how workforce users authenticate to Entra ID. |
| IA-5 — Authenticator Management | The campaign governs the lifecycle of user authenticators and registration state. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Useful where the campaign extends to external populations or partner identities. | |
| Recommendation — Enforce strong workforce authentication requirements only after enrolment is reliably in place. Manage authenticator enrolment, recovery, and replacement as controlled lifecycle events. Apply distinct enrolment rules when the prompted population is outside the workforce. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Campaigns are part of governing identity enrolment and authentication change. |
| Recommendation — Maintain identity enrolment rules that match the authentication policy you intend to enforce. | ||
Practitioner Guidance
What to verify: Confirm that the campaign targets the right population, excludes break-glass accounts, and has a defined recovery path for users who fail enrolment on the first attempt. Also verify that the method being promoted is the one you actually intend to rely on at sign-in, not a transitional fallback.
What to measure: Track completion rate, failure reasons, and the volume of support contacts triggered by the campaign. If failures are concentrated in one device class or user group, fix that path before broadening the rollout.
Decision rule: Keep the sign-in policy loose until the target population shows sustained successful enrolment and successful use of the new method. If adoption stalls, adjust communications or exception handling before adding more enforcement.
Practitioner takeaway: Treat the campaign as a controlled adoption programme, not a cosmetic prompt, because the real objective is dependable enrolment at scale before policy becomes stricter.
Related resources from NHI Mgmt Group
- How do you detect device registration without MFA in Microsoft Entra ID?
- How do you investigate AI agent sign-ins in Microsoft Entra Agent ID?
- How do you secure a Model Context Protocol (MCP) server with Microsoft Entra ID?
- How do you secure third-party AI agents such as Amazon Bedrock with Microsoft Entra Agent ID?