How to answer
Is multi-factor authentication enforced for administrative access?
The gap here is almost always between "enabled" and "enforced", and between staff logins and the two or three accounts that could not take a second factor.
Yes. MFA is enforced for all administrative access to production systems, including the cloud console, VPN and privileged database accounts. Enforcement is applied at the identity provider and cannot be bypassed by individual users.
FillTrust grades an answer like this confirmed in your documents when your documents support it.
- Answered from
- Your access control standard, and the identity section of your SOC 2 report.
- Evidence to attach
- Occasionally a screenshot of the enforcement policy in your identity provider. Never a list of users.
- Where it is asked
- CAIQ v4.0 · IAM-14SIG LiteISO 27001 Annex A · A.8.5
There are two different questions hiding in this one, and answering the easy one is what gets teams caught.
The easy question is whether your staff sign in with a second factor. Almost certainly yes, through an identity provider, and it takes one line to say so.
The hard question is whether anything can get to production without it. That is where the real answers live: the cloud provider root account that predates your identity provider, the CI service account with deploy permissions, the database superuser that a runbook says to use when the pooler is down, the legacy admin panel behind a password that three people know. None of those are unusual and none of them are disqualifying. What is disqualifying is answering a flat yes and having one of them surface later.
The useful distinction to write down is enforcement point. If MFA is required by a policy in your identity provider and every path to production goes through that provider, you can say it is enforced and cannot be bypassed by a user, which is a strong answer. If it is switched on per-account and a user could switch it off, the accurate word is "enabled", and a reviewer will read the difference.
For the accounts that genuinely cannot take a second factor, the answer that works is to name the compensating control rather than to omit them: the root account's credentials are held in a sealed vault, are not used in normal operation, and their use raises an alert. That reads as a team that has thought about it. Silence reads as a team that has not.
How this one goes wrong
Specific to this question, not general advice.
- "Enabled" is not "enforced". If a user can turn it off, or if a fallback login path skips it, the honest answer is that it is available and not required.
- Break-glass and service accounts. Root credentials and CI service accounts are the ones that usually cannot take a second factor, and a reviewer who asks a follow-up will ask about exactly those.
- Answering for staff SSO while a legacy admin panel still accepts a password alone.