A municipality is modernizing identity: a central directory, MFA for remote access, and federation to cloud SaaS used by multiple departments. What implementation priority best keeps those pieces coherent?
Select an answer to reveal the explanation.
Short Explanation
Directory, MFA, and federation are a trio, not three science-fair projects. Point apps at one identity story with MFA and federation so nobody invents yet another password island.
Full Explanation
Modern municipal authentication succeeds when directory services, MFA, and federation/SSO are selected and integrated so one coherent identity source and authentication policy cover on-prem and departmental SaaS. Consistency prevents conflicting password silos, uneven MFA coverage, and orphaned cloud identities that no longer track HR status. Implementation priority is architectural coherence—not isolated point products that never share policy.
Deploying a separate username/password silo per SaaS app and skipping federation multiplies credentials, weakens lifecycle revoke, and trains users toward reuse. Disabling MFA until every legacy NTLM app is rewritten holds remote-access security hostage to the slowest legacy dependency; phased MFA with compensating controls on holdouts is the usual professional path. Replacing the directory with shared local admin accounts on each server abandons centralized identity entirely and maximizes standing privilege.
Exam caveat: federation and MFA questions often tempt “wait until legacy is gone”—prefer phased integration with a clear directory-of-record. Operational check: designate the city directory as authoritative, federate SaaS via standards-based SSO, enforce MFA on remote and privileged paths first, inventory apps still outside the mesh, and verify leaver events disable both on-prem and federated sessions promptly.