Transit helpdesk can reset AD passwords, so password alone is too weak for a VPN-like SaaS app in Hub. What should the administrator require?
Select an answer to reveal the explanation.
Short Explanation
If the helpdesk can mint a new password, that password is a spare house key—not a second lock. Put OTP or a certificate after password on the Access policy so a reset alone cannot open the SaaS app.
Full Explanation
Stack a second Access authentication method such as OTP or certificate after password on the policy for the VPN-like SaaS app so transit helpdesk password resets cannot alone unlock Hub access. When helpdesk can reset AD passwords, password becomes a single weak factor under insider or social-engineering pressure; Access policy must require an additional method the helpdesk reset does not grant. Password only explicitly fails that threat model for a sensitive transit SaaS application in Hub. Carbon Black device control is endpoint device-control policy, not a second Access authentication factor presented at Hub login. NSX identity firewall without an Access policy change may filter traffic by identity but does not add MFA at the Access login for the SaaS application. Exam caveat: stacking methods on the Access policy is how Hub MFA is expressed—adjacent VMware security products are common distractors on VCP-SEC items. Operational check: add OTP or certificate after password on that policy, verify a freshly reset password alone cannot open the app, test legitimate MFA success, and document the stacked methods in the transit authority identity runbook for civic rider-operations SaaS protection.