CC6.1: Logical access and MFA
Failing MFA tests are the most common CC6.1 findings. Deixic turns the enforcement on, waits for an approver where the change removes people, and re-runs the test with a receipt attached.
What CC6.1 asks
CC6.1 asks that the company limit who can reach its systems and data, and that each person proves who they are before they get in.
The auditor tests this through multi-factor authentication on the identity provider, the code host, and the cloud console.
Source: AICPA Trust Services Criteria (2017, with revised points of focus 2022). This page paraphrases the criterion.
Tests that fail, and what Deixic does
Each row is a test from your compliance platform and the change Deixic makes in the connected system.
| Failing test | What Deixic does | Authority |
|---|---|---|
| MFA is enforced for every userGoogle Workspace, Microsoft 365 | Turns on enforced 2-step verification with a 7-day enrollment period for new users. Microsoft 365 gets the equivalent sign-in requirement. | Runs under written policy |
| Two-factor authentication is required for the GitHub organizationGitHub | Lists every member without two-factor, then turns on the organization requirement. | Waits for a named approver |
| Console users have MFAAWS | Attaches a policy to each console user without a device that blocks everything except MFA enrollment. | Runs under written policy |
| Sign-on policy requires a second factor for every applicationOkta, Google Workspace | Edits the sign-on policy rule so every application sign-in asks for a second factor. | Waits for a named approver |
| Service accounts and shared logins are exempt from MFAGoogle Workspace, AWS, Okta | Lists each exempt account with its last sign-in and owner. Deixic grants no exemption. | Goes to you as a decision |
What waits, and what Deixic refuses
Approvals name a person and record a reason. Decisions are actions outside the authority your policy grants.
Waits for a named approver
- Turning on the GitHub organization two-factor requirement. GitHub removes members who have not enrolled, so the approver reads the list first.
- Changing the Okta or Google sign-on policy rule that applies to every user.
Never run without your decision
- Exempting any account from MFA. Deixic lists the account and its owner and asks for a written reason.
- Changing the AWS root user password, email, or MFA device.
- Removing the last sign-in method on a break-glass account.
What Deixic reads back
After each change Deixic reads the setting from the system itself.
| System | Read back |
|---|---|
| Google Workspace | Enforcement flag per organizational unit and the count of enrolled users. |
| GitHub | Organization two-factor setting and the member list after the change. |
| AWS | IAM credential report: every console user with an MFA device. |
| Okta | The sign-on policy rule as stored, including its priority. |
Evidence your auditor receives
One signed, hash-linked receipt per change, exported as PDF, HTML, or JSON.
- Each setting before and after the change
- The read-back response from each system
- The accounts the change touched
- Approver, reason, and timestamp where an approval applied
- The re-run result of the test in your compliance platform