IAM TechThe observation
Ask most organisations how their users authenticate and you will get an answer about the identity provider. Ask how their service accounts authenticate, or their APIs, or their Linux estate, or the account someone uses when the identity provider itself is unavailable, and the answer becomes noticeably less confident.
This is not a knowledge gap. It is a documentation gap. The mechanisms exist and work; what does not exist is an agreed position on which ones the organisation is deliberately investing in, which it is tolerating for now, and which it intends to remove.
Without a stated position, every integration becomes a fresh negotiation — and the path of least resistance usually wins.
What we have seen
Where no reference model exists, the same consequences follow:
- Legacy mechanisms quietly acquire new dependencies. Nobody decided to extend Lightweight Directory Access Protocol (LDAP) bind authentication to a new application; there was simply no documented reason not to.
- Machine identity is designed last, or not at all. Human authentication gets the architecture attention; service accounts get whatever the integration needed on the day.
- Decommissioning stalls indefinitely. You cannot retire a mechanism when nobody can enumerate what depends on it.
- Assurance varies invisibly. Two applications may both claim Single Sign-On (SSO), but one enforces Multi-Factor Authentication (MFA) and the other inherits a session established hours earlier by a password alone.
A reference model
This is the shape of the standard we would expect an enterprise to hold. It is deliberately expressed as patterns rather than products — the strategic choice is the pattern, and any number of vendors implement each one.
| Pattern | Typical position | What decides it |
|---|---|---|
| Workforce | ||
| Cloud identity provider (IdP) SSO (OIDC) | Strategic | The default for anything new. Native to modern applications, works properly on mobile. |
| Security Assertion Markup Language (SAML) 2.0 | Strategic for existing estate | Still the lingua franca of enterprise Software as a Service (SaaS). Not a reason to avoid, but not where new build should start. |
| Kerberos / Windows integrated | Transitional | Works well inside a domain, assumes a perimeter that is disappearing. |
| LDAP bind authentication | Legacy only | Credentials handled by the application. Migrate rather than extend. |
| NT LAN Manager (NTLM) | Legacy only | Should be on an active decommissioning plan, not a standards list. |
| Local application accounts | Exception only | Every instance needs a named owner and an expiry date. |
| Passwordless — Fast Identity Online 2 (FIDO2), passkeys | Strategic direction | The only widely available phishing-resistant option. Plan enrolment and recovery first. |
| MFA | Mandatory | Non-negotiable for privileged and high-risk access; number matching as the floor. |
| Infrastructure | ||
| Directory authentication | Standard | Fine for server access, provided privileged accounts are separated. |
| Secure Shell (SSH) key authentication | Standard (Linux) | Keys need the same lifecycle as passwords — most estates have no inventory. |
| Remote Desktop Protocol (RDP) authentication | Standard (Windows) | Should be brokered rather than direct. |
| Privileged | ||
| Brokered session access | Strategic | Session established by the platform, credential never revealed to the user. |
| Credential vaulting and rotation | Strategic | The baseline control. Rotation without inventory is false comfort. |
| Just-in-Time (JIT) elevation | Strategic | Removes standing privilege — the single biggest reduction in blast radius. |
| Machine | ||
| Group managed service accounts | Preferred where supported | Removes the password from human hands entirely. |
| Service accounts | Governed lifecycle | Needs an owner, a purpose, a review date. Usually has none of the three. |
| OAuth 2.0 client credentials | Strategic | The correct pattern for service-to-service API access. |
| Cloud service principals / workload identity | Strategic | Scope tightly; these accumulate permissions quietly. |
| Certificate authentication (mTLS) | Strategic | Strongest option for system-to-system. Expiry is the classic outage cause. |
| API | ||
| OAuth 2.0 with JSON Web Token (JWT) bearer tokens | Preferred | Validate issuer, audience, scope and expiry — not merely the signature. |
| API keys | Legacy / integration-specific | No expiry, no scope, no identity. Tolerable only with compensating controls. |
| Federation | ||
| Cross-tenant / partner federation | Where required | Trust the assertion only as far as you trust the other side's authentication. |
| On-premises federation services | Transitional | Migrate to the cloud IdP where the application supports it. |
| Emergency | ||
| Break-glass accounts | Controlled exception | Excluded from conditional access by design, so monitoring must be absolute. |
The positions matter more than the list. Any competent architect can enumerate authentication mechanisms. The value is in an organisation committing to which are strategic and which are being retired — because that is what turns individual integration decisions into a direction of travel.
How to use it
- Fill in the "what decides it" column with your own constraints. A regulated estate and a startup will reach different positions on the same mechanism, and both can be correct.
- Publish it where integration decisions are actually made. A standard that lives in an architecture repository nobody reads changes nothing.
- Attach each legacy row to a decommissioning owner. "Legacy only" without an owner is simply a description of the status quo.
- Review it when the estate changes, not annually. Acquisitions and cloud migrations are what invalidate these positions.
Key takeaways
- Most estates have more authentication mechanisms than they have documented positions on them.
- Standardise on the pattern, not the product — patterns outlive vendor decisions.
- Machine, API and emergency access deserve the same architectural attention as workforce login, and rarely get it.
- "Legacy only" is a commitment to remove something. Without a named owner it is just an adjective.