During a security assessment, the utility discovers that every technician on the NOC team logs in to the FortiGate using one shared super_admin account, since it was the only account created at deployment time. What is the main problem with continuing this practice, and what should replace it?
Select an answer to reveal the explanation.
Short Explanation
One shared login means your audit log can never say which technician actually made a change. Split the team into named accounts, each scoped to a profile matching their real job, and you bring back both individual accountability and the principle of giving people only the access they need.
Full Explanation
A single shared super_admin account used by an entire team creates two compounding problems: every technician holds full read-write access regardless of whether their role requires it, violating least privilege, and because logins and changes all attribute to the same shared identity, the audit trail can't distinguish which individual performed a given action. The fix is a named administrator account per technician, each bound to an access profile scoped to that person's actual responsibilities, so permissions match role and every logged action traces back to a specific person. Claiming there's no real problem ignores both the accountability and least-privilege failures inherent in credential sharing, regardless of whether the permissions happen to be sufficient. Giving each technician their own copy of the same super_admin password solves nothing — it's still one identity from an auditing standpoint, and password expiration is unrelated to the accountability problem. Restricting the shared account's trusted hosts to the NOC subnet may reduce external login risk, but it does nothing to separate accountability or restrict permissions per role. To validate the fix, review the audit log after the change and confirm each configuration event is now attributed to a distinct named account.