Archetype

Expanded Definition

An archetype is the presentation and handling layer that tells an identity platform how a managed object should look and behave in the interface, without changing the underlying authorisation model. In midPoint-style designs, it shapes UX intent, default views, naming, and lifecycle handling, while roles and policies continue to govern access decisions. That separation matters because an archetype can make a service account appear operationally distinct from a human user, even when both are governed under the same control plane.

Definitions vary across vendors and implementation styles, so archetype should be treated as an interface and management construct rather than a security primitive. For example, it may influence which tabs, attributes, or workflows administrators see, but it should not be used to grant privileges, bypass approval steps, or encode entitlement logic. For security teams, the practical question is whether the identity object is being displayed and managed in a way that matches its actual risk profile and operational purpose, as described in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

The most common misapplication is treating archetype as a permission boundary, which occurs when teams assume UI grouping or object labeling changes the actual access posture.

Examples and Use Cases

Implementing archetypes rigorously often introduces modelling overhead, requiring organisations to balance cleaner administration and clearer lifecycle handling against additional design and maintenance work.

• A service account archetype can expose rotation status, ownership, and workload context so operators manage it as an NHI rather than as a generic user record.
• An API client archetype can surface token expiry, secret location, and dependency mapping to support faster incident response and better offboarding discipline, a pattern aligned with guidance in the Ultimate Guide to NHIs.
• A machine identity archetype can simplify provisioning screens for platform teams while keeping role assignment and policy enforcement separate from presentation logic, consistent with NIST Cybersecurity Framework 2.0 governance principles.
• A contractor or partner identity archetype can distinguish external operational accounts from internal staff accounts, helping admins apply the right review cadence and naming convention.
• An automation agent archetype can present execution scope, tool access, and owner metadata so the platform reflects the agent’s actual operational footprint.

Why It Matters in NHI Security

Archetypes matter because NHI environments fail when the platform makes dangerous identities look ordinary. If service accounts, API keys, and agents are presented with the same default handling as human users, teams lose visibility into ownership, rotation, and offboarding requirements. That confusion contributes to the broader NHI exposure problem documented by NHI Management Group, including the finding that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface in the Ultimate Guide to NHIs.

Archetypes also support governance by making it easier to present the right metadata to the right operator. When an organisation can tell at a glance whether an object is a human user, workload identity, or automation agent, it is easier to enforce lifecycle controls, spot orphaned identities, and avoid mistaken approvals. This aligns with the access and lifecycle discipline expected in the NIST Cybersecurity Framework 2.0, where identity hygiene is part of operational resilience.

Organisations typically encounter the need for archetype rigor only after a compromise, when incident responders discover that a supposedly routine account was actually an unmanaged service identity with hidden operational reach.

Related resources from NHI Mgmt Group

• AI deployment archetype