> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MFA should be enabled for all users

> Checks that every Gcore Customer Portal user has two-step verification enabled.

## What this check does

DSALTA lists the account's Customer Portal users with the connected token, reads each user's two-step verification flag and records whether the account enforces two-step verification as supporting evidence. A user whose flag is not reported as enabled counts as not enabled.

<Note>
  This check also runs on 25 other integrations — see [MFA should be enabled for all users](/tests/mfa-should-be-enabled-for-all-users) for the full list.
</Note>

<Info>
  This check reads the live user list on every run, not the Access page. It also reads whether the account enforces two-step verification and attaches that policy to the result as supporting evidence; the policy never decides the outcome, so a user without the flag fails the check even on an enforcing account. If Gcore returns no users at all — which cannot happen on a working token, because the Administrator who created it is a portal user — the run ends in an error rather than a pass, so a broken credential is never mistaken for full two-step coverage.
</Info>

| | |
| - | - |
| **Severity** | High |
| **Category** | `access` |
| **Data used** | Gcore account user list, Per-user two-step verification status, Account two-step verification enforcement |

**Passes when:** Every Customer Portal user of the Gcore account has two-step verification enabled. A user without a readable flag counts as not enabled, and the check needs at least one user to evaluate.

## Why this matters

Gcore Customer Portal users can change DNS records and CDN origins for the company's public sites and create API tokens that automate the whole account. Two-step verification on every user keeps a stolen password from being used to redirect that traffic.

## How to fix

**Enforce two-step verification in Gcore**

1. Ask each flagged user to sign in to the [Gcore Customer Portal](https://portal.gcore.com), open **Profile → Security**, and enable two-step verification.
2. As an account Administrator, open **Account settings** and enforce two-step verification for all users, so that no user can leave it off.
3. Run the check again from **Compliance → Tests**, or wait for the next scheduled run, and confirm no user is still reported without two-step verification.

Once resolved, DSALTA records a **200** (compliant) result on this test's **Source Data** tab at the next scheduled run.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="How often does this check run?">
    Once a day, at 02:00 America/New\_York, while the integration is connected. A run is skipped entirely if the integration is not in a **connected** state, or if the test has been deactivated.

    To see a fix reflected sooner, open the test from **Compliance → Tests** and click **Run** in the **Run Test** row. You need Full Access to run a test on demand.
  </Accordion>

  <Accordion title="What does the status actually tell me?">
    The **Status** column answers "did the check run?", not "did I pass". **Completed** means DSALTA reached your system and finished evaluating — a check that ran and *found a problem* is still Completed.

    To see what it found, open the test and read the result code on the **Source Data** tab. **200** means nothing to fix; **204** means the check did not apply to your environment; **207** means it ran and found a compliance gap you need to act on. See [Understanding test results](/guides/compliance/test-results).
  </Accordion>

  <Accordion title="The check shows Failed. Does that mean I am non-compliant?">
    Usually not. On an integration-powered check, **Failed** means DSALTA was *blocked* and could not evaluate it — result code **403** (a missing permission) or **428** (a setting DSALTA still needs from you). Code **500** means the run failed on DSALTA's side.

    A genuine compliance gap does not turn the list red — it runs to completion and shows **207**.
  </Accordion>

  <Accordion title="What if this check does not apply to us?">
    Deactivate it: open the test from **Compliance → Tests**, then use the **⋮** menu at the top right of the panel and choose **Deactivate Test**. It applies immediately, with no confirmation step.

    Write your justification in the **Comments** tab **before** you deactivate. Once deactivated, every other tab is grayed out, so Comments is the only place an auditor can read why — see [Test detail](/guides/compliance/test-detail).
  </Accordion>

  <Accordion title="Does DSALTA change my configuration?">
    No. DSALTA only reads. It never creates, modifies, or deletes resources, and every remediation step is performed by your team directly in the third-party product.
  </Accordion>
</AccordionGroup>