Shared certificates break accountability. When multiple people can use the same DSC, it becomes difficult to prove who authorised a filing, contract, or transaction. That uncertainty increases the chance of misuse, identity theft, and disputed actions. Strong controls depend on individual ownership, private password handling, and clear approval boundaries before any signature is applied.
Why This Matters for Security Teams
Shared digital signature Certificates create a fraud problem because they collapse three things security teams need to keep separate: identity, authority, and accountability. If one certificate is used by multiple people, the signature may prove that “someone with the shared secret signed,” but it does not reliably prove who acted, whether approval was valid, or whether the signer was coerced or impersonated. That weakens nonrepudiation and makes disputes harder to resolve.
This is not just a policy issue. Shared use turns a certificate into an access token with no durable attribution, which is exactly the kind of pattern that shows up in higher-risk NHI environments discussed in NHIMG research such as the Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks. NIST guidance also emphasises that access control and auditability depend on traceable identity events, not pooled credentials, as reflected in the NIST SP 800-53 Rev 5 Security and Privacy Controls.
NHIMG research on machine identity governance found that 59% of companies face greater difficulties auditing machine identities because of unclear ownership and limited visibility, and shared certificates create the same failure pattern for people-driven signing workflows. In practice, many security teams encounter disputed signatures only after a filing, payment, or contract has already been challenged.
How It Works in Practice
The fraud risk increases because shared DSCs break the chain of custody around a signature. When a certificate private key, password, or signing token is reused across a team, any one of those users can produce the same cryptographic output. That makes the signature technically valid but operationally weak: it cannot easily answer who initiated the action, who approved it, and whether the signer had legitimate business authority at that moment.
Current guidance suggests replacing shared use with individual ownership, per-user signing controls, and strong audit logging. That means each signer should have a unique certificate or a tightly controlled delegated signing path, with explicit approval before a signature is applied. Where transaction risk is high, organisations should also pair signing with step-up verification, maker-checker approval, and revocation procedures that can isolate compromised credentials quickly. The same principle that drives stronger workload identity in the Ultimate Guide to NHIs — What are Non-Human Identities applies here: the certificate should map to one accountable principal, not a shared group.
- Assign one certificate to one person or one clearly defined legal entity.
- Protect private keys with individual passwords, hardware-backed storage, or approved signing devices.
- Log signer identity, timestamp, transaction context, and approval evidence for every signing event.
- Revoke or rotate certificates immediately when a user leaves, changes role, or is suspected of misuse.
For broader identity governance, the control model should align with NIST Cybersecurity Framework 2.0 and the principle that strong identity assurance depends on unique attribution, not credential sharing. These controls tend to break down in high-volume back-office environments where one shared certificate is embedded into legacy workflows and business teams resist per-user signing because it slows transaction throughput.
Common Variations and Edge Cases
Tighter signing controls often increase operational overhead, requiring organisations to balance fraud reduction against user friction and support cost. That tradeoff is real, especially where notarisation, bulk filing, or third-party portal access was designed around a single pooled certificate. In those environments, the answer is usually not to keep sharing the certificate, but to redesign the workflow so accountability stays intact.
There is no universal standard for this yet across all jurisdictions and platforms, so teams should treat local legal requirements as binding and apply current best practice rather than assuming a single technical model will satisfy every regulator. eIDAS 2.0, for example, strengthens the direction of travel toward traceable digital trust, but implementation details still vary by use case. NHIMG’s The Critical Gaps in Machine Identity Management report shows why: 57% of organisations lack a complete inventory of their machine identities, which is a warning sign for any certificate-based control regime.
Edge cases include automated signing services, outsourced processors, and shared service desks. In those cases, best practice is evolving toward delegated authority with named operators, immutable logs, and tightly scoped approval windows rather than generic shared access. If the organisation cannot attribute a signature to a specific human or legal principal at review time, the fraud risk remains elevated even when the certificate is cryptographically sound.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shared certificates create poor ownership and rotation discipline. |
| NIST CSF 2.0 | PR.AC-4 | Access control must preserve attributable, least-privilege signing. |
| NIST SP 800-63 | IAL2 | Fraud risk rises when identity proofing cannot map actions to one person. |
| NIST Zero Trust (SP 800-207) | PL-1 | Zero trust requires explicit verification before every signing action. |
| NIST AI RMF | Accountability and traceability are core AI-risk governance principles. |
Assign one owner per cert and rotate or revoke it immediately on role change or suspected misuse.
