A must, should, can structure is a way of ranking security requirements by importance. Must items are mandatory, should items are strongly recommended, and can items are optional. This makes governance clearer, supports phased rollout, and helps teams defend decisions during audits or transition periods.
Expanded Definition
A must, should, can structure is a priority-ranking method for security requirements. Must denotes mandatory controls, should signals strong recommendations that may be deferred with justification, and can marks optional guidance or enhancements. In NHI governance, this structure is useful when teams need to separate non-negotiable controls such as secret rotation or access review from improvements that can be staged later.
Definitions vary across vendors and policy authors, so the labels themselves are not a formal standard. Their value comes from making intent explicit during design, audit, and remediation planning. This is especially useful when requirements span engineering, security, and compliance functions, because each group may otherwise interpret urgency differently. The most common misapplication is treating should as effectively mandatory without documenting the risk decision, which occurs when teams copy policy language into controls without assigning accountability.
For broader control mapping, the NIST Cybersecurity Framework 2.0 provides a useful governance lens for prioritising outcomes, while NHI-specific interpretation is best grounded in Ultimate Guide to NHIs.
Examples and Use Cases
Implementing a must, should, can structure rigorously often introduces process overhead, requiring organisations to weigh clearer governance against slower policy publication and more review steps.
- Must: Every API key used by an agent must be stored in a secrets manager and rotated on a defined schedule, because leaving credentials in code creates direct exposure.
- Should: Service accounts should use short-lived credentials where feasible, but a legacy integration may require a phased transition with documented exception handling.
- Can: Teams can add alert enrichment or automated dashboards for NHI inventory review when operational maturity supports it.
- Must: Privileged agent access must be tied to explicit approval and logging, especially for systems that can modify infrastructure or data stores.
- Should: Organisations should classify NHI policies by rollout stage so auditors can see what is mandatory now versus what is planned later.
In practice, this structure helps teams translate lessons from the Ultimate Guide to NHIs into phased controls, while keeping policy language consistent with the outcome-focused framing used in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
NHI security fails quickly when requirement priority is ambiguous. A must, should, can structure reduces confusion during secret rotation, agent onboarding, and incident response by showing what has to be done immediately and what can be scheduled later. That distinction matters because NHI environments often contain large numbers of service accounts, API keys, and automation credentials with uneven ownership and inconsistent lifecycle controls.
NHI Mgmt Group data shows why this clarity matters: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. Without explicit priority language, teams can mistake deferred work for acceptable risk acceptance, or treat a recommendation as a hard control after an audit finding. The structure also supports better cross-functional accountability when security, platform, and compliance teams need to agree on staged remediation.
Organisations typically encounter the cost of unclear priority only after a secrets leak or privilege incident, at which point the must, should, can structure becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Prioritised controls help separate mandatory NHI safeguards from phased improvements. |
| NIST CSF 2.0 | GV.OV | Governance outcomes benefit from explicit prioritisation and exception handling. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust implementations depend on clear minimum access and staged hardening decisions. |
| NIST AI RMF | GOVERN | AI governance needs transparent policy ranking to manage risk and remediation sequencing. |
| OWASP Agentic AI Top 10 | AGENT-02 | Agentic systems need explicit control tiers for tool access and execution authority. |
Rank agent controls so the most critical restrictions are mandatory before broader autonomy is allowed.
Related resources from NHI Mgmt Group
- How should organisations structure AI governance before focusing on compliance?
- How should security teams structure access governance in a federated enterprise?
- How should security teams structure crisis decision rights before an incident happens?
- How should startups structure security coverage before hiring a full team?
