Who should certify application access in a governance process?

The most practical owner is usually the manager or audit owner closest to the business need, because they can judge whether the access still makes sense. The process should preserve accountability by recording who certified the access, what was reviewed, and how long the approval remains valid. That creates a defensible access record.

Who should certify application access in a governance process?

Certification should sit with someone who can judge business need and risk, not just technical ownership. In practice, that is usually the application owner, service owner, or line manager with direct accountability for the access being reviewed, plus a control owner where the access is sensitive or high impact. The point is to confirm that the access is still justified, correctly scoped, and time-bounded.

Why Access Certification Needs a Real Business Owner

Access certification fails when it becomes a routing exercise instead of an accountability decision. A certifier needs enough context to answer three questions: does this access still support a live business function, is the level of privilege appropriate, and does the approval remain valid for the period in question. Without that context, reviews drift toward rubber-stamping or blanket revocation, both of which create governance noise rather than control.

For application access, the right certifier is usually the person closest to the business use case and the risk of misuse. That may be a manager for human access, or an application owner or audit owner for system access. Where the access involves privileged functions, production data, or regulated workflows, the certifier often needs support from security, IAM, or the control owner to validate scope and exceptions. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because certification is not only about approval, but about creating evidence that can survive audit and later investigation.

In practice, many organisations discover that access certification is weakest where ownership is shared but accountability is not.

How Certification Works When It Is Governed Well

Good certification processes separate ownership, review, and enforcement. The certifier decides whether the access remains justified; IAM or the platform team enforces the decision; audit and security define the control standard and the review cadence. That separation matters because the person with operational knowledge is not always the person who should change entitlements, and the person who changes entitlements should not be the sole approver of their own access.

For ordinary application access, a manager or business owner can usually certify whether a user still needs the application and whether the role matches the job. For shared accounts, service accounts, API keys, and other machine or application credentials, the certifier should be the application owner or system custodian, because they can judge whether the account is still required and whether the permission set matches the intended function. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs helps frame this distinction: credentials should be reviewed as living assets with owners, expiry expectations, and offboarding obligations, not as static permissions left to age in place.

A practical certification record should show who approved, what was reviewed, which system or entitlement was covered, and when the approval expires. Where applications expose sensitive data or privileged administrative functions, reviews should also capture whether the access was validated against current role scope and whether any exception was accepted. That level of detail matters because auditors and investigators need to see decision quality, not just decision presence. The OWASP Non-Human Identity Top 10 also reinforces the importance of ownership, lifecycle, and least privilege for machine-access relationships, which is often the same governance problem wearing a different label.

These controls tend to break down when access is approved in bulk across many applications without evidence of entitlement-level review, because the certifier no longer has enough context to make a defensible decision.

Common Variations and Edge Cases

Stricter certification often increases review burden, so organisations need to balance governance quality against approver fatigue and review latency. The right approach depends on the access type, sensitivity, and change frequency.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, ordinary employee access is often certified by the manager or business owner. Second, application access tied to a specific system function is often certified by the application owner or service owner. Third, elevated, shared, or production access usually needs dual input: a business owner to confirm need and a control owner or security function to validate risk and exception handling. NHIMG’s Top 10 NHI Issues is a useful reminder that over-privilege and weak lifecycle discipline become operational problems quickly once access is inherited rather than actively governed.

One edge case is outsourced or third-party access, where the immediate requester may not be the right certifier because they do not own the business outcome. Another is non-human access, where a human manager cannot meaningfully attest to the necessity of a token, certificate, or service credential without support from the system owner. The best rule is simple: the certifier must be able to defend why the access is needed, but they do not need to be the person who technically administers it.

Risk and Threat Considerations

Access certification is a governance control, but weak certification creates direct exposure when stale or excessive access remains active. The main risk is not the review itself; it is the false confidence that comes from approvals that are vague, mis-scoped, or detached from actual system ownership.

Failure mechanism: When a certifier lacks business context, reviews become rubber-stamps, and over-privileged or no-longer-needed access remains in place. That can preserve dormant access paths for misuse, insider abuse, or later compromise, especially when approval evidence is not tied to a clear entitlement and expiry.

Impact: The result is weak accountability, harder investigations, avoidable privilege accumulation, and greater blast radius if an account, application, or credential is misused. For machine and application access, poor certification also slows offboarding and makes it difficult to prove that access was intentionally granted and intentionally retained.

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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	5 — Account Management	Access certification is a core account review and entitlement governance activity.
	6 — Access Control Management	Certifiers are validating whether application access remains appropriately scoped.
Recommendation — Review accounts regularly and remove or reapprove access that is no longer justified. Enforce least privilege and require approval for access changes to sensitive systems.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Certification supports governance over who can access which applications and why.
	GV.RM — Risk Management Strategy	Sensitive access certification should align with risk appetite and control ownership.
Recommendation — Define approval and review responsibilities for access rights and entitlement changes. Assign review authority according to risk and document exception handling for high-risk access.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	Application and machine access need a clear owner for accountable certification.
	NHI-03 — Least Privilege and Scope	Certifiers should verify that access remains narrowly scoped to business need.
Recommendation — Assign each non-human access path an accountable owner and review it on a fixed cadence. Reapprove only the minimum access needed and remove unused or excessive privileges.

Practitioner Guidance

What to prioritise: Put certification authority as close as possible to the business purpose of the access, then add a higher-control reviewer only when the entitlement is privileged, shared, regulated, or production-facing. If the reviewer cannot explain why the access exists, they are not the right certifier.

What to verify: Verify that each certification record names the entitlement, the approver, the business justification, and the review expiry. Also verify that the person certifying non-human or application access actually owns the system outcome, not just the request ticket.

Practitioner takeaway: The strongest governance is not the most senior approver; it is the approver who can make a defensible, time-bounded decision about whether the access still belongs.

Who should certify application access in a governance process?