Start with the reference architecture that defines the approved access pattern across authentication, integration, and workflow design. That gives teams a common baseline for implementation and review, instead of letting every site or application team invent its own version of secure access.
Standardise the reference architecture before you standardise individual implementations
The first thing identity and IAM leaders should standardise is the approved access pattern itself: how authentication happens, how applications integrate with the identity layer, and how workflow steps are designed. That creates a shared baseline for teams, reduces local variation, and makes review simpler because security decisions are happening against one known model rather than many ad hoc versions.
In practice, this means defining the pattern at the level where design choices become repeatable. A strong reference architecture covers the identity provider, trust boundaries, session handling, approval path, and the rules for when a team can use a standard pattern versus request an exception. IAM and IGA Basics is a useful companion here because the programme will only stay consistent if the access model, entitlement model, and governance model are aligned from the start.
Teams usually move faster once the approved path is explicit. If every application team invents its own login flow, token handling, or approval logic, the programme becomes a collection of one-off designs that are hard to support. If the reference architecture is clear, teams can still solve for their application needs, but they do so within guardrails that preserve consistency, auditability, and operational supportability.
What the reference architecture must settle early
The architecture should answer the questions that create design drift: which authentication methods are approved, where policy decisions live, what integration standards are required, and how human and non-human access flows differ. For cloud and workload-heavy environments, that also includes the pattern for temporary credentials and workload identity rather than static secrets. Cloud Workload Identity Guide shows why that matters, because a modern access programme often fails when teams are allowed to default to long-lived keys or inconsistent federation patterns.
The best reference architectures are opinionated enough to be usable but not so rigid that they break legitimate application constraints. They should define the non-negotiables, such as approved trust relationships, identity proofing expectations, logging requirements, and exception handling. They should also define the common integration path for standard apps so delivery teams can implement quickly without redesigning access from scratch each time.
A useful test is whether a new application team can read the architecture and answer, in one sitting, how users authenticate, how the app gets tokens or assertions, and how access is reviewed or revoked. If they cannot, the programme has not yet standardised enough to scale.
Why standardisation starts with design, not cleanup
Leaders often want to begin with inventory cleanup, entitlement rationalisation, or policy enforcement, but those steps work much better after the architecture is settled. Without a reference pattern, cleanup becomes a temporary fix, because new exceptions keep appearing in the next implementation wave. With a reference pattern, remediation and build work point in the same direction.
That is why standardisation should be treated as a programme design decision, not just an implementation task. The architecture defines what good looks like, the control set defines how it is measured, and the delivery teams then implement against the same model. CSA Cloud Controls Matrix is a helpful external control reference for this kind of cross-environment standardisation because it gives leaders a structured way to map IAM, governance, and operational control expectations across cloud implementations.
Once the baseline is defined, teams can be allowed to specialise only where the architecture permits it. That is the real value of standardisation: it creates a default path that accelerates delivery while making deviations visible, reviewable, and exception-based rather than accidental.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Standardised access patterns depend on consistent account lifecycle governance. |
| IA-2 — Identification and Authentication (Organizational Users) | The reference architecture must standardise how users authenticate across apps. | |
| IA-5 — Authenticator Management | Programme consistency depends on standard handling of credentials, tokens, and secrets. | |
| Recommendation — Define account lifecycle rules that every application must follow. Mandate a single approved user authentication pattern. Standardise how authenticators are issued, stored, rotated, and revoked. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The programme needs a common access-control baseline across teams and systems. |
| Recommendation — Set one access-control baseline for all delivery teams. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access programmes need repeatable account and entitlement governance. |
| Recommendation — Centralise account and entitlement standards before local exceptions proliferate. | ||
Practitioner Guidance
What to prioritise: Standardise the access pattern that every team will reuse before you standardise edge-case policies or local tooling. The first deliverable should be a reference architecture, not a policy memo.
What to verify: Confirm the architecture is specific enough that a delivery team can implement authentication, integration, and workflow without inventing hidden dependencies. If the document still leaves core decisions open, it is not yet a programme baseline.
Decision rule: If a team’s proposed pattern deviates from the approved model, treat it as an exception requiring explicit review rather than a new normal. That keeps the programme from fragmenting into site-by-site designs.
Practitioner takeaway: The fastest way to scale an Epic access programme is to make the secure path repeatable first, then let teams optimise within that path instead of around it.
Related resources from NHI Mgmt Group
- Where does cross-environment agent discovery fit in an IAM programme?
- How should ICS leaders assess digital identity maturity before trying to standardise access across connected NHS organisations?
- What should security leaders do first when they want to modernise identity governance without losing control of access risk?
- What is the difference between identity governance and privileged access management in a converged IAM programme?