Secure by design is now an identity governance issue

At a glance

What this is: This discussion frames secure by design as an identity and access problem, showing how weak verification, social engineering, and retrofit security break down in practice.

Why it matters: It matters because IAM, PAM, and NHI programmes all fail when trust is assumed too early, too broadly, or without strong verification at the point of access.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Bitwarden's discussion on secure by design, passkeys, and identity verification

Context

Secure by design means building identity verification, access control, and failure handling into the system from the start rather than trying to add them later. In identity programmes, that principle matters because the cost of retrofitting controls rises once human users, service accounts, and operational workflows are already relying on weak assumptions.

The article uses human authentication failures, password managers, and passkeys to show that security is not only a code issue. It is also a governance issue for IAM teams that have to decide where trust begins, where it ends, and which controls must exist before access is granted.

Key questions

Q: How should security teams stop help desk social engineering from becoming an access path?

A: Treat the help desk as part of the identity control plane. Require strong caller verification, separate recovery approvals from routine support, and make every reset or exception traceable to an owner. If support staff can bypass identity checks for convenience, attackers can use the same path to gain legitimate-seeming access.

Q: Why do secure-by-design programmes fail when identity controls are added too late?

A: They fail because access patterns, fallback routes, and user expectations are already fixed in production. Late controls create gaps, exceptions, and inconsistent enforcement. Identity security has to be built into architecture, recovery, and offboarding from the start or the organisation inherits avoidable trust debt.

Q: How do passkeys change identity risk for organisations?

A: Passkeys remove password reuse and reduce phishing exposure, but they shift risk into enrollment, device trust, recovery, and lifecycle management. Organisations that treat passkeys as a simple login upgrade miss the real governance challenge, which is ensuring the identity is issued, recovered, and revoked correctly.

Q: Who should own security evidence for authentication and recovery workflows?

A: IAM, PAM, and application owners should jointly own the evidence because authentication is only as strong as the supporting process. Teams should be able to show standards alignment, documented recovery paths, and clear revocation logic. That evidence is what distinguishes real security from security theatre.

Technical breakdown

Why retrofitting identity controls fails after deployment

Retrofit security fails because identity paths, trust relationships, and recovery workflows have already been embedded in production. Once help desk processes, password reset flows, and user support patterns are live, they become part of the attack surface. A secure-by-design posture forces identity verification, recovery, and exception handling to be defined before rollout, not after the first incident. That is why late control insertion usually creates friction, inconsistent enforcement, and hidden bypasses.

Practical implication: design verification and recovery paths before deployment, then test them as part of acceptance criteria.

Passkeys, phishing resistance, and human identity security

Passkeys shift authentication away from shared secrets and toward asymmetric key pairs, which removes password reuse and greatly reduces phishing exposure. In practice, they change the failure mode from credential theft to device and lifecycle governance. That means the real work moves to enrollment, recovery, device trust, and offboarding. For IAM teams, passkeys are not just a better login method. They are a different operating model for human identity assurance.

Practical implication: treat passkey rollout as an identity lifecycle programme, not a front-end login tweak.

Open source transparency and the security evidence test

The panel’s argument about transparency maps well to identity governance. Security claims need evidence in the form of standards alignment, documented cryptographic handling, vulnerability disclosure, and clear operational controls. In IAM and NHI programmes, the same logic applies to service accounts, secrets stores, and passwordless systems: if teams cannot explain how trust is established and revoked, they do not actually control it. That turns transparency into a governance requirement, not a communications exercise.

Practical implication: require traceable evidence for authentication, recovery, and revocation controls before approving production use.

Threat narrative

Attacker objective: The objective is to obtain legitimate-seeming access by abusing human verification and support workflows, then use that access to reach protected systems.

1. entry: an attacker bypasses technical defenses by using social engineering against the help desk rather than exploiting software directly.
2. credential_harvested: the attacker obtains password reset access through a trusted support process and uses it to take over the target account.
3. impact: access to highly secure systems is gained without a technical exploit, showing that identity verification failure can become a full compromise path.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secure by design becomes an identity governance test the moment support workflows can be abused. The article’s MGM example shows that technical strength at the platform layer does not matter if identity recovery is weak. Help desk resets, fallback channels, and exception handling are now part of the control surface, not administrative convenience. IAM teams should treat every recovery path as production access.

Identity verification cannot be postponed until after the user base and recovery model are live. Security-by-retrofit creates a governance debt that is expensive to unwind because the organisation has already normalized the weak process. This is true for human identity, but it also carries forward into NHI operations where secrets, tokens, and service accounts are often inherited into production with minimal proof of control. The practitioner conclusion is that verification design must precede scale.

Passkeys shift the control problem from secret reuse to lifecycle governance. That is a healthier failure mode, but it is not a free pass. Enrollment, recovery, device trust, and offboarding now determine whether phishing resistance actually holds in practice. For IAM leaders, this means modern authentication only improves security when identity lifecycle discipline keeps pace.

Transparency is the security evidence layer that separates claims from control. The panel’s emphasis on standards, documentation, cryptographic clarity, and vulnerability handling mirrors what mature IAM programmes already demand of NHI and privileged access systems. If an organisation cannot show how trust is established, verified, and withdrawn, the security claim is incomplete. Practitioners should insist on operational evidence, not slogans.

Secure by design reduces rework, but only when identity decisions are made at architecture time. The central lesson is that identity failures are cheaper to prevent than to unwind. In human IAM, NHI governance, and passwordless adoption, the same principle holds: the earlier the trust model is explicit, the less likely the organisation is to inherit hidden bypasses later. The practitioner takeaway is to make identity design a prerequisite, not a cleanup task.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• For a deeper lifecycle lens, see Ultimate Guide to NHIs , What are Non-Human Identities for how governance must cover service accounts, tokens, and other machine identities.

What this signals

Secure by design is becoming a lifecycle issue, not just a development principle. As passwordless adoption grows, the real governance question shifts to enrollment, recovery, and revocation across human and machine identities. Teams that still treat those steps as operational detail will keep inheriting hidden access paths. The first priority is to make recovery evidence visible and reviewable across the IAM programme.

The same logic now applies to NHI estates, where trust is often weaker than teams assume. When organisations cannot even see most service accounts, they cannot prove that security was built in rather than bolted on. That makes the case for identity inventory, control ownership, and explicit revocation workflows stronger than any individual product choice.

Identity blast radius: the practical measure of how far a bad recovery path, weak fallback, or unmanaged secret can spread. In programmes that span human IAM and NHI governance, the safest control is the one whose failure can be isolated quickly and whose evidence can be verified without guesswork.

For practitioners

• Map every account recovery path to an access control owner Document who approves recovery, what proof is required, and which fallback channels are allowed before any login change goes live. Treat help desk reset workflows as privileged access paths and review them alongside PAM controls.
• Move phishing-resistant authentication into the default standard Prioritise passkeys or equivalent phishing-resistant methods for users who can support them, then define enrollment and recovery as governed lifecycle steps rather than optional convenience features.
• Test security claims against operational evidence Ask teams to show standards alignment, vulnerability handling, and cryptographic process documentation before approving new authentication or support workflows. If the control cannot be explained end to end, it is not ready for production.
• Apply the same design discipline to NHI recovery and offboarding Service accounts, API keys, and automation tokens need explicit recovery, replacement, and revocation steps so that support shortcuts do not become standing access. Use the Ultimate Guide to NHIs as the baseline for lifecycle design and control scope.

Key takeaways

• Secure by design fails when identity recovery, fallback, and verification are treated as afterthoughts.
• The evidence gap is already visible in machine identity governance, where most organisations lack full service-account visibility.
• Practitioners should make authentication, recovery, and revocation part of architecture design, not post-deployment cleanup.

Key terms

• Secure by Design: A secure-by-design approach builds identity and security controls into the architecture before systems are deployed. It reduces the need for retrofits and limits hidden trust paths, especially in authentication, recovery, and access delegation flows that attackers commonly abuse.
• Phishing-Resistant Authentication: Phishing-resistant authentication uses methods that do not rely on reusable shared secrets, such as passkeys or cryptographic authenticators. The goal is to make credential theft through social engineering much harder, while shifting governance attention toward enrollment, recovery, and device trust.
• Recovery Workflow: A recovery workflow is the process used to regain access when a user loses credentials or cannot complete normal authentication. In identity governance, it is a high-risk control path because it can bypass stronger front-door protections if verification and approval are weak.
• Identity Control Plane: The identity control plane is the set of policies, workflows, approvals, and systems that decide who or what gets access and how that access is verified or revoked. It includes support channels, recovery processes, and lifecycle controls, not just login screens.

What's in the full article

Bitwarden's full article covers the operational detail this post intentionally leaves for the source:

• The panel’s first-hand discussion of secure-by-design decision-making in product and infrastructure teams.
• Specific examples of how password managers, passkeys, and biometric prompts change real user workflows.
• The original commentary on social engineering, security theatre, and why transparency matters in practice.

👉 The full Bitwarden post covers the panel discussion, practical examples, and user-facing security guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.