8.2 MFA Registration Campaigns & Risky Workloads
Key Takeaways
- MFA registration campaigns and authentication methods registration experiences nudge or require users to register strong methods before hard Conditional Access enforcement.
- Combined security info registration reduces helpdesk load by letting users set MFA and SSPR methods in one flow; campaigns target users who still lack usable methods.
- Workload identities (service principals / apps) can be risky without interactive MFA—monitor app sign-ins, credentials, permissions, and Identity Protection workload signals differently from human user risk.
- Protect workload identities with credential hygiene (certificates over secrets where possible), least-privilege app permissions, Conditional Access for workload identities where supported, and regular review of risky service principals.
- Do not apply user-centric remediations (password change, Authenticator push) as the primary control for a compromised multi-tenant app or service principal secret.
From risk policy to registration reality
Section 8.1 showed how sign-in risk and user risk drive Conditional Access. Those policies fail operationally if users have not registered multifactor methods. SC-300 therefore treats registration campaigns and authentication methods registration as first-class identity operations—part of Domain 2 readiness before aggressive enforcement.
Separately, Domain 3 skills (workload identities) and ID Protection’s expansion to workload identity risk mean you must also secure service principals—apps and automation identities that never receive an Authenticator push. This section bridges human registration campaigns and risky workload monitoring.
Authentication methods registration (foundation)
Before campaigns, remember the control planes:
| Surface | Role |
|---|---|
| Authentication methods policy | Which methods are enabled and scoped (Authenticator, FIDO2, TAP, CBA, etc.) |
| Combined registration (My Security Info) | User experience to register MFA + SSPR methods together |
| MFA registration campaign / registration campaign settings | Nudge or interrupt users who are not registered yet |
| Conditional Access / Security defaults | Require MFA or other grants at access time |
Order of operations for safe rollout:
- Enable desired methods in authentication methods policy (pilot groups → broader).
- Communicate https://aka.ms/mysecurityinfo (or successor My Account security info links).
- Turn on registration campaign to drive completion.
- Use report-only Conditional Access MFA/risk policies; fix registration gaps.
- Enforce CA; keep TAP and helpdesk proofing for exceptions and joiners.
If you skip to step 5, you create an outage that looks like “MFA is broken” but is actually no registered methods.
MFA registration campaigns
A registration campaign proactively prompts users who have not registered multifactor authentication methods to set them up. Microsoft Entra can show intermittent or required registration experiences so users complete security info before you flip enforcement to “always require MFA.”
Why campaigns appear on SC-300
| Problem | Campaign value |
|---|---|
| Users ignore optional registration emails | In-product prompts at sign-in increase completion |
| CA MFA about to go live | Reduce day-one lockouts |
| Risk-based MFA for medium sign-in risk | Users must already have a method when risk fires |
| Passwordless / phishing-resistant roadmap | Drive Authenticator/FIDO2 registration early |
Typical configuration concepts
Exact blade names evolve (often under Protection > Identity Protection or authentication methods / registration campaign experiences). Know the ideas:
| Setting concept | Exam meaning |
|---|---|
| State (Off / Microsoft-managed / Custom) | Whether Microsoft runs a default campaign or you customize |
| Days between prompts / snooze behavior | How often users can postpone |
| Included users/groups | Pilot IT first, then all users |
| Excluded users/groups | Break-glass, kiosks, special populations |
| Limited vs required registration experiences | Soft nudge versus harder interrupt depending on product options |
Microsoft-managed campaigns are useful when you want Microsoft’s recommended prompting without deep customization. Custom campaigns appear when you need specific groups, snooze intervals, or staged enablement.
Campaign versus Conditional Access MFA
| Capability | Registers methods? | Enforces MFA at app access? |
|---|---|---|
| Registration campaign | Yes (drives enrollment) | Not a substitute for CA grants |
| Conditional Access “Require MFA” | Only if user can complete challenge; fails if unregistered | Yes |
| Security defaults | Includes registration pressure + baseline enforcement | Coarse tenant baseline |
| Per-user legacy MFA | Older enrollment/enforcement model | Legacy; prefer CA + methods policy |
Exam stem: “Users will be locked out tomorrow when CA requires MFA; many never registered.” Correct near-term actions: registration campaign + communication + TAP for stragglers, not “delete the CA policy permanently” or “disable all methods.”
Combined registration and SSPR alignment
Combined registration lets users set methods used for MFA and self-service password reset in one wizard. Align:
- Methods allowed in authentication methods policy
- Methods allowed for SSPR
- What the campaign tells users to register
Misalignment example: SSPR requires mobile phone SMS, but methods policy disables SMS and campaign pushes FIDO2 only—users complete “registration” yet still fail SSPR or MFA for some apps. Design one method strategy, then express it consistently.
For hybrid joiners, combine campaigns with TAP onboarding so passwordless users can register FIDO2/Authenticator without standing passwords (see earlier authentication chapters).
Workload identities: not just “users without MFA”
A workload identity is a non-human identity used by an application, service, script, or automation. In Microsoft Entra, the directory objects you manage day-to-day are often:
| Identity | Typical use |
|---|---|
| Service principal | Instance of an app in a tenant; authenticates as the app |
| Application registration | App definition/object; credentials and permissions defined here |
| Managed identity | Azure-hosted workload identity without secrets you manage in code |
Humans get user risk and interactive MFA. Workloads authenticate with client secrets, certificates, federated credentials, or managed identity tokens. Attackers love stolen app secrets because:
- No push notification alerts a person.
- Secrets may be long-lived if poorly rotated.
- Over-privileged Graph application permissions can read mail, files, or directory data at scale.
- Multi-tenant apps can affect many customers if consent is broad.
Risky workload identities (service principals)
Microsoft Entra ID Protection capabilities for workload identities surface risk on service principals (product names evolve: “risky workload identities,” workload identity risk detections). SC-300 expects you to know they exist, where to investigate, and how remediation differs from users.
Differences from user risk scenarios
| Topic | Users | Workload identities |
|---|---|---|
| Primary secret | Password + MFA methods | Client secret, cert, federated cred, managed identity |
| Risk examples | Leaked password, impossible travel | Leaked credentials, suspicious API traffic patterns, anomalous auth |
| Self-remediation | MFA + password change | No Authenticator self-heal; admin rotates credentials |
| CA response | Require MFA, password change, block user | Workload identity CA (where licensed/supported), block app, restrict tokens |
| Investigation focus | Sign-in logs, MFA, device | App sign-in logs, credential activity, permissions, consent, owners |
| Confirm/dismiss | Risky user dispositions | Risky service principal dispositions / disable app |
Protect workload identities (SC-300 control set)
- Prefer managed identities for Azure-hosted code when possible (no secret in config).
- Prefer certificates or federated identity credentials over long-lived client secrets.
- Enforce secret expiration and rotation; alert on credentials approaching expiry or newly added.
- Apply least privilege: application permissions only as needed; avoid wild Directory.ReadWrite.All style grants without review.
- Restrict who can consent; use admin consent workflows.
- Assign owners to enterprise apps/service principals for accountability.
- Use Conditional Access for workload identities (feature/licensing dependent) to limit which apps or conditions service principals can meet—exam-level awareness that CA is expanding beyond users.
- Monitor Identity Protection risky workload identities and Entra app sign-in logs.
- For suspected compromise: disable the service principal / app, remove or rotate credentials, revoke refresh tokens / app sessions as applicable, review audit logs for Graph/API abuse, re-enable only with new credentials and reduced permissions.
Investigation workflow (workload)
| Step | Action |
|---|---|
| 1 | Open risky workload identity / service principal risk report |
| 2 | Identify app display name, app ID, owners |
| 3 | Review credentials (secrets/certs) added recently—unexpected adds are red flags |
| 4 | Review API permissions and admin consents |
| 5 | Review sign-in logs for service principal (IP, resource, failure/success) |
| 6 | Check automation owners: expected pipeline vs unknown script |
| 7 | Contain: disable + rotate; do not “require MFA on the secret” |
| 8 | Post-incident: shorten credential lifetime, move to managed identity/cert, tighten CA |
MFA campaigns and workloads together (exam scenarios)
Scenario A — Human readiness: Org enables sign-in risk MFA next month. Deploy Authenticator in methods policy, start registration campaign for all users excluding break-glass, track registration reports, then turn CA on.
Scenario B — Leaked app secret: Automation SP shows as risky workload; secret may be in GitHub. Disable SP, delete secret, create certificate credential, move app to managed identity on Azure, review Graph calls in audit logs—not “send the SP a registration campaign email.”
Scenario C — Confusion trap: Stem says “risky user” but describes a daemon app. Choose service principal credential rotation, not user password change.
Operational metrics to watch
| Metric | Why it matters |
|---|---|
| % users registered for MFA | Predicts CA enforcement success |
| Campaign snooze / defer rates | Who still needs outreach |
| Number of high-risk users open | SOC/identity backlog |
| Service principals with expiring secrets | Proactive rotation |
| Apps with unused highly privileged permissions | Attack surface reduction |
| Workload identities flagged risky | Non-human compromise queue |
Common traps
- Enabling risk-based CA before registration campaigns mature.
- Thinking registration campaigns replace Conditional Access MFA.
- Applying user password change remediation to a compromised client secret.
- Leaving multi-year client secrets on privileged apps.
- Ignoring app owners and consent sprawl while focusing only on human MFA.
- Believing managed identities need registration campaigns.
Bridge to Global Secure Access
ID Protection and registration harden who may authenticate and under what risk. Microsoft Entra Global Secure Access (next section) extends Zero Trust to how traffic reaches private apps and the internet—including Microsoft 365—using Security Service Edge patterns identity admins must recognize on SC-300.
Your organization will enforce Conditional Access Require MFA for all users in two weeks, but registration reports show many users have no methods enrolled. What should you prioritize now?
A daemon application’s client secret appears to be leaked and Identity Protection flags the service principal as a risky workload identity. Which response is most appropriate?
How does an MFA registration campaign differ from a Conditional Access policy that requires multifactor authentication?
Which statement best contrasts user risk remediation with workload identity protection?