Domain: Information
Question:
A small healthcare-tech company is rebuilding its security program after a failed audit uncovered widespread over-privilege and long-lived credentials that accumulated under a "fail-fast" culture. The company is modernizing around Microsoft's Cybersecurity Reference Architecture (MCRA) and a Zero Trust posture, but leadership wants to avoid a strategy that treats access as something you "clean up" during periodic reviews--because permissions can drift again between reviews and because heavy, manual governance will slow engineering delivery. Given that engineers still need to ship quickly (and will continue to change projects, responsibilities, and environments), how should the organization redesign identity and access governance so that privilege is continuously constrained and auditable by default, while still allowing developers to do their jobs? In your response, address how to identify and correct risky permission patterns already in place (for example, privileged actions performed through everyday "daily driver" identities), how to separate routine user activity from administrative activity, and how to rely on time-bounded elevation and distributed enforcement rather than permanent, standing access or a single centralized "gate."

Expected points in a correct answer:
States that, under MCRA, access governance must operate continuously rather than through periodic access reviews
mentions periodic "cleanup" of permissions is insufficient to prevent privilege drift.
States that privilege should be temporary, contextual, and identity-bound by default rather than permanently granted
mentions a method for identifying excessive or risky permission assignments already in place.
Identifies "daily driver" identities performing privileged actions as a risky pattern
recommends separating routine user activity from administrative activity
States that daily driver/standard user accounts should not be capable of performing administrative actions such as granting access permissions, managing identity providers, or modifying production IAM roles."
recommends time-bounded elevation rather than permanent privileged access.
explains how time-bounded elevation reduces the window of exposure
describes a mechanism for granting elevated access only when required for a defined task
rejects reliance on a single centralized "gate" for access approval.
connects distributed enforcement with Zero Trust assumptions.
describes enforcement occurring at multiple control points rather than only at initial account provisioning
states that access decisions and privilege elevations must be auditable by default.
mentions continuous auditability supports regulatory expectations in healthcare environments.
avoids proposing manual approval processes for routine engineering tasks
describes automation as a mechanism for enforcing access constraints without slowing teams.
Mentions that identity should serve as the primary control plane under MCRA Zero Trust
Identifies specific categories of routine vs. administrative activities (e.g., code commits and sandbox development as routine; production configuration changes and IAM role assignments as administrative)
States that privileges should expire automatically without requiring manual revocation
Mentions stronger authentication assurance as a control for administrative context
Explains that over-privilege accumulates because engineers retain access after role changes and temporary permissions are never revoked
Mentions that long-lived static credentials for service accounts are a risky pattern to address
Identifies CI/CD pipelines as one of the distributed enforcement points