Citizen-service contractors must access a municipal portal without sharing one department password among the crew. Which approach best matches modern authentication guidance?

Modern authentication guidance for municipal portals starts with unique identities for every person who needs access, including citizen-service contractors. Each contractor should sign in as themselves so activity is attributable, permissions can be least-privileged, and access can be revoked when a contract ends. Layering multifactor authentication or passwordless methods further reduces the risk that a single shared secret grants the whole crew standing access. That combination—individual identity plus stronger methods—matches Microsoft Entra best practice at Azure Fundamentals depth.

Publishing a shared password on an internal wiki and rotating it yearly preserves a communal secret that cannot identify who acted and is likely to leak across vendors. Disabling authentication and trusting only VPN IP allowlists confuses network location with proof of identity; stolen or shared endpoints still open the portal. Storing contractor passwords in a public Blob container exposes credentials to anyone who can reach the container URL and is never an acceptable identity pattern.

Exam caveat: external/guest identities are often the right lifecycle model for contractors, but the core principle on this item is still “no shared passwords”—unique principals come first regardless of employee versus guest status.

Operational check: create or invite one identity per contractor, assign only the portal’s required app role or group membership, require MFA or passwordless, and verify that the old shared password no longer works against the municipal portal.