Identity and access: who owns it on each service model
Who has an account, which role it holds, whether a second factor is required, and who reviews it. The provider secures the sign-in service; the accounts in your tenancy are almost always yours.
The split by service model
| Service model | Owner | Why, and the clause |
|---|---|---|
| Infrastructure as a service | yours | The accounts, roles and second factors inside your tenancy are yours to grant, review and remove; the provider secures only its own staff's privileged access. ISO/IEC 27017 9.2.3 |
| Platform as a service | yours | The accounts, roles and second factors inside your tenancy are yours to grant, review and remove; the provider secures only its own staff's privileged access. ISO/IEC 27017 9.2.3 |
| Software as a service | shared | The provider runs the sign-in service and its administrative plane; who holds an account, which role it carries and whether a second factor is enforced are yours. ISO/IEC 27017 9.2.3 |
| Serverless functions and event services | yours | The accounts, roles and second factors inside your tenancy are yours to grant, review and remove; the provider secures only its own staff's privileged access. ISO/IEC 27017 9.2.3 |
| Hosted AI models and AI platforms | yours | The accounts, roles and second factors inside your tenancy are yours to grant, review and remove; the provider secures only its own staff's privileged access. ISO/IEC 27017 9.2.3 |
Services that move the line
- Identity provider: yours The identity provider is where every other account is decided: its administrators, its policies and the second factor it enforces are yours; the provider runs only the service.
The clauses each framework attaches
7 quoted| Framework | Clause |
|---|---|
| Cloud Controls Matrix v4.0.1 | CCM-IAM-14 Strong Authentication |
| ISO/IEC 27017:2015 | ISO/IEC 27017 9.2.3 Management of privileged access rights |
| SOC 2 Trust Services Criteria | SOC 2 CC6.2 Prior to granting access, registration and authorization processes are established |
| ISO/IEC 27001:2022 Annex A | ISO/IEC 27001 5.18 Access rights |
| CMMC 2.0 | CMMC AC.L2-3.1.1 Authorized Access Control ยท CMMC IA.L2-3.5.3 Multifactor Authentication |
| FedRAMP Moderate | FedRAMP AC-2 Account Management |
CCM-IAM-14 Strong AuthenticationAuthenticate access to systems, applications and data, using multifactor authentication at minimum for privileged users and sensitive data, and digital certificates or equivalent strength for system identities.
- Authentication configuration per system showing the factors required
- Evidence multifactor authentication covers all privileged users and sensitive data access
- The mechanism used for system identity authentication
- Exception records where multifactor authentication is not applied
- Multifactor authentication enforced at the perimeter but bypassable by direct application access
- Service and system identities authenticating with static shared secrets
- Exceptions granted with no expiry or compensating control
ISO/IEC 27017 9.2.3 Management of privileged access rightsPrivileged access in a cloud service sits on both sides. The customer should control the privileged rights it holds over its tenancy, using strong authentication and keeping the number of privileged users small, and the provider should control privileged access of its own staff to the cloud service and to customer environments, with the assurance the customer asks for. The provider should offer sufficient authentication techniques for the customer's privileged accounts.
- List of privileged cloud accounts on the customer side with approvals
- Provider description of privileged access controls for its staff
- Evidence of multi-factor authentication on privileged cloud accounts
- Provider root or console credentials shared between customer staff
- No statement from the provider on how its administrators reach customer environments
SOC 2 CC6.2 Prior to granting access, registration and authorization processes are establishedPrior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by
- The registration and authorisation procedure that must complete before credentials are issued, for internal and external users
- Authorisation records for users provisioned in the period, showing the requester, the approver and the access requested
- Evidence credentials were issued only after authorisation, with dates supporting the sequence
- Evidence of removal of access when access is no longer authorised, with the interval between the trigger and the removal
- Evidence covering users whose access is administered by the entity on behalf of a customer, where that applies
- Access granted first and approved retrospectively, which reverses the order the criterion requires
- Approval by the requester's peer or by the person implementing the change, so no independent authorisation exists
- External and customer administered users provisioned through a different route with no equivalent authorisation record
- Removal triggered by a manual notification that is sometimes not sent, so leavers retain credentials
ISO/IEC 27001 5.18 Access rightsProvision, review, modify and remove access rights in line with the access control policy.
- Access provision records
- Access review reports
- Access revocation logs
- Role definition documents
- Reviews lack documented corrective actions
- Access changes not tied to approved request workflow
- Legacy accounts remain active after employee departure
- Role definitions not updated to reflect current business processes
CMMC AC.L2-3.1.1 Authorized Access Control Level 1 and 2Restrict system access so only identified, authorized users, the processes running on their behalf, and approved devices including other connected systems can connect.
- Account inventory listing authorized users, service/process accounts and approved devices
- Account provisioning and approval records showing authorization before access
- System configuration showing device and system-to-system connection allow lists
- Periodic account recertification results
- Service and machine accounts never authorized or reviewed
- Device-level access unrestricted while user access is controlled
- Stale accounts retained after staff depart
CMMC IA.L2-3.5.3 Multifactor Authentication Level 2Require more than one authentication factor for privileged account access both locally and across the network, and for non privileged account access across the network.
- Multifactor configuration showing coverage of the required access cases
- Enrolment records for privileged account holders
- Evidence of enforcement for network access by non privileged users
- Multifactor applied to remote access only, missing local privileged access
- Exemptions granted for service or legacy accounts without compensating control
- Second factor is another knowledge factor
FedRAMP AC-2 Account ManagementManage accounts; review at least monthly for privileged, every six months for non-privileged (FedRAMP); notify within FedRAMP-defined timeframes on changes.
- Control implementation statement for AC-2 citing the system mission and inheritance from common controls
- Joiner mover leaver workflow evidence integrated with HR
- Access control policy approved by the information security officer
- Role-based access matrix mapped to job functions and data classifications
- Account provisioning and deprovisioning workflow tickets with manager approvals
- Quarterly privileged access review attestations
- Stale accounts retained for terminated personnel beyond the 24 hour SLA
- Privileged accounts shared across administrators without individual accountability
- Access reviews performed but exceptions never remediated
- Role definitions drift from documented matrix without change control