How can organisations combine CBA and MFA without adding unnecessary friction?

Use certificates to anchor endpoint trust and MFA to strengthen user authentication at the point of access, then narrow the combination to applications that justify the overhead. Pair the design with hardware-backed storage and clear onboarding and offboarding processes so security improves without turning identity operations into a manual bottleneck.

Why This Matters for Security Teams

Combining certificate-based authentication with MFA sounds simple, but the friction usually appears where identity operations, endpoint trust, and application policy meet. Certificates can verify that a device or workload is in a known state, while MFA proves a person is present at the point of access. The challenge is to use both without forcing every login into a high-friction ceremony that users will work around or support teams will eventually bypass.

That tradeoff matters because identity controls fail quietly when they become too burdensome. In real environments, the risk is not only weaker user experience, but also shadow exceptions, shared accounts, and manual approval paths that become permanent. The NIST Cybersecurity Framework 2.0 treats identity assurance as part of a broader governance problem, not a one-time login prompt. For organisations also dealing with non-human identities, the scale of the problem is stark: NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises in its Ultimate Guide to Non-Human Identities.

In practice, many security teams encounter certificate and MFA friction only after users have already created workarounds, rather than through intentional design.

How It Works in Practice

The cleanest pattern is to treat CBA and MFA as complementary signals, not competing gates. Certificates establish device or endpoint trust, while MFA strengthens the human authentication step when access is actually requested. That lets the organisation avoid repeating heavy challenges for every action and instead reserve stronger prompts for higher-risk events, new devices, privilege elevation, or sensitive applications.

A practical rollout usually starts with policy segmentation. Applications that expose sensitive data, admin functions, or regulated workflows get the full combination of certificate validation plus MFA. Lower-risk apps may rely on certificate-backed session assurance alone, especially when device posture is already strong. Current guidance suggests that this should be driven by policy-as-code and risk context, not by static identity tiers. The NIST Cybersecurity Framework 2.0 is useful here because it encourages repeatable access control and governance decisions rather than ad hoc exceptions.

To reduce friction, organisations typically pair this model with:

• Hardware-backed certificate storage so keys are not exportable from the endpoint.
• Conditional MFA that triggers only when risk changes, rather than on every session refresh.
• Automated enrolment, renewal, and revocation so certificate lifecycle steps do not become help desk work.
• Clear joiner, mover, and leaver processes so onboarding and offboarding are deterministic.

This is especially important when identities are already hard to inventory. NHI Mgmt Group notes in the Ultimate Guide to Non-Human Identities that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that identity friction often grows fastest where governance is weakest. These controls tend to break down when legacy apps cannot validate certificates consistently because authentication exceptions then become the default operating model.

Common Variations and Edge Cases

Tighter certificate plus MFA controls often increase deployment and support overhead, requiring organisations to balance stronger assurance against user productivity and application compatibility.

There is no universal standard for exactly when both factors are required. Current practice varies by application sensitivity, device management maturity, and regulatory exposure. For example, high-value admin portals may justify CBA and MFA on every access, while everyday productivity apps may only need MFA at session start if the endpoint certificate is already strong. The real design question is where to spend user friction for measurable risk reduction.

Edge cases usually involve contractors, shared workstations, break-glass accounts, and legacy systems that cannot support modern certificate validation. Those environments often need compensating controls such as shorter sessions, stronger monitoring, or limited privilege scope. Organisations should also be careful not to extend the same login model to workloads and automation. Certificates for endpoints are not the same as workload identity, and mixing those use cases creates confusion that can weaken both. In the most mature deployments, teams review access telemetry and revocation timing together so cert trust and MFA policy evolve as one control plane.

For teams looking at broader identity risk, the Microsoft Midnight Blizzard breach is a reminder that credential strength alone does not prevent abuse when lifecycle and exception handling are weak.

Related resources from NHI Mgmt Group

• How should organisations implement PSD2 controls without adding too much checkout friction?
• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams replace traditional MFA without creating new access friction?
• How should security teams reduce phishing risk in MFA without creating more user friction?