AI fraud targets the perception layer: voice, face, document appearance, writing style. Precisely where humans decide whether something is trustworthy, the cost of convincing forgeries has collapsed. A cloned voice from three seconds of audio, a deepfake face in a live video call, an invoice with a swapped IBAN reproduced to pixel-perfect layout accuracy: these attacks have been documented over the past 18 months, in central Switzerland (the Schwyz CEO fraud in January 2026, losses of several million francs), in German trades businesses (a roofer in September 2025, nearly €27,000 lost to IBAN manipulation), and in HR departments across Europe where North Korean operatives with synthetic identities signed employment contracts. Anyone wanting to read the cases in detail will find them on our AI fraud overview page.

As a Swiss Trust Service Provider, we set out here how you can respond to such attacks technically — how to move from "looks authentic" to "cryptographically verifiable". We show how this shift works architecturally, which attack classes it counters, where its limits lie, and how a signature service can be integrated into an existing system landscape.

We are not claiming that qualified electronic signatures (QES) or regulated seals are immune to AI. They protect against three specific attacks: those targeting document integrity, the authenticity of the issuer or signatory, and the binding of a signature or seal to the identity of a person or organisation.

This article is aimed at Security Officers, Application Architects, and Enterprise Architects who need to answer how a signature solution actually fits into their stack and which regulatory anchors need to be observed. It complements our practical guide for functional decision-makers, which covers the same six use cases from a process perspective.

1. The Layer Shift: From Perception to Verification

AI has made the perception layer unreliable. Cryptographic signatures and seals make trust a technically unambiguous decision.

Generative AI has drastically reduced the cost of convincing forgeries at the perception layer. Voices for a phone call can be reconstructed from three seconds of audio. Faces are replaced live in video calls. Document layouts are replicated perfectly, often including the specific typefaces and print artefacts of the original. Writing styles can be imitated from minimal training data. The attack surface that has grown over the past two years is precisely the one on which humans evaluate trustworthiness.

Cryptographic signatures and seals do not operate at this layer. They do not try to beat the forger at the perception level. They replace probabilistic human judgement with deterministic technical verification: in electronic signatures and seals, document content is bound to an identity via asymmetric cryptography — the second part of this article explains how that works in detail. But first, to the points that attackers are exploiting with AI in ways that are new or at greater scale than previously known.

2. Five AI Attack Vectors and How the Gap Closes

Five concrete attack classes from the real threat landscape: which gap is exploited, how QES or seals close it, and where the limits of each case lie.

Vector 1: Deepfake Video Interviews in Hiring

Attack: A candidate with a synthetic or stolen identity passes the video interview using a live deepfake, uploads a generated ID scan, and submits forged diplomas and references. Pindrop, a US provider for voice fraud detection, found in 2025 that a single job posting attracted over 800 applications, more than one third of which were entirely fabricated.

Gap: Visual and conversational impression is no longer sufficient for an identity decision. Human detection of deepfakes is barely above chance.

Closing: Issuing a QES requires a formal identification process against a government-issued identity document with physical or NFC-based security features, carried out by a certified Trust Service Provider under an audited procedure. The signature on an employment contract therefore no longer means "the person looked genuine on video" but rather "the person passed the qualified identification process and holds a private key bound to this verified identity". This barrier is substantially higher than passing a video interview. To forge the contract, an attacker must no longer merely produce convincing audio-visual output but must attack the trust infrastructure itself: the regulated identity verification procedure and sole control over the verified signatory's private key.

Limits: QES does not prevent deepfake-based interviews, but it does prevent an effective contract being concluded by an unidentified person. The protection lies not in the interview but at the point of contract execution.

Vector 2: Voice-Cloned Instructions or Compromised Email Accounts

Attack: A phone call with a cloned voice or a hacked email account of a business partner triggers changes to contracts, bank details, or delivery addresses. The Schwyz CEO fraud in January 2026 is the documented Swiss reference case: several million francs transferred to Asia, triggered by a cloned voice on the phone.

Gap: Verbal or email-based instructions are accepted as authorisation in many organisations, even though they carry no cryptographic binding to an identified person.

Closing: QES moves authorisation out of the verbal or email channel. A convincing phone call alone cannot generate a signature. The legitimate key holder must complete an authentication and signature activation process with the Trust Service Provider. In remote QES architectures, this involves multi-factor authentication combined with a SCAL2-compliant signature confirmation. The signatory thereby explicitly authorises the specific cryptographic signing operation under a regulated process that ensures sole control. Only the actually responsible person at a partner organisation can produce this signature.

Limits: If the downstream process continues to accept verbal instructions without a signature step, QES does not help. That was precisely the weakness in the Schwyz case: the transfers ran outside any contract process, triggered directly by phone instructions. The architecture must require a signature as a hard precondition for contract changes, payment instructions, and delivery amendments; otherwise the gap remains open.

Vector 3: AI-Manipulated Invoices in Transit

Attack: A PDF invoice is intercepted between issuer and recipient. An AI tool replaces the IBAN while the layout is preserved perfectly; the recipient notices nothing. In the September 2025 roofer case, attackers gained access to the owner's email inbox, manipulated the IBAN in the PDF, and forwarded the invoice. Only an attentive accounts clerk prevented the payment.

Gap: The recipient cannot visually detect whether the PDF was altered in transit. A changed IBAN looks identical to the original.

Closing: The issuing organisation's regulated electronic seal binds document content to the issuing organisation via its cryptographic hash. Any modification after sealing — including a single changed digit in the IBAN — alters the document hash and cryptographically invalidates the seal. The recipient's verification tool, any standard PDF reader or the free federal validator, flags this automatically.

Limits: S/MIME protects the email channel, but only as long as the email travels through the original channel and a key exchange has taken place. The seal protects the document itself, regardless of the transmission path, including repeated forwarding or printing. Both mechanisms complement each other; neither fully replaces the other.

Vector 4: Synthetic Identities in Account Opening and Policy Issuance

Attack: KYC processes are overcome with AI-generated or stolen identity artefacts that appear authentic to automated checks. A German pet health insurer documented multiple cases in 2024 and 2025 in which canine operations were fabricated using AI-generated X-ray images and forged invoices, based on purely machine-generated identities.

Gap: Image-based verification does not help against high-quality forgeries. A PDF copy of an identity document is trivially generatable.

Closing: QES prevents synthetic identity fraud not primarily at the document level but at the level of identity establishment. Before a qualified certificate can be issued, the applicant must complete a regulated identity verification process with a Trust Service Provider, based on government-issued identity documents and audited verification procedures, with biometric chip reading where possible. This is auditable against a defined regulatory standard, specifically the FINMA Circular 2016/7, eIDAS requirements, and ETSI TS 119 461. Synthetic identities do not survive this step because they cannot produce an authentic identity document.

Limits: Genuine stolen identities combined with further attack elements (stolen document plus deepfake plus a cooperating person for the liveness check) remain a residual risk. The barrier is, however, substantially higher than with purely image-based checks, and the Swiss e-ID and EUDI Wallet will further strengthen this protection in future.

Vector 5: AI-Generated Forged Certificates and Diplomas

Attack: A candidate presents a forged diploma from a reputable university. Visually it is indistinguishable from the original because generative AI convincingly replicates layout, seals, signatures, and paper texture. Google Threat Intelligence documented fabricated degrees from European universities in the North Korean IT worker programmes, generated in precisely this way.

Gap: Visual inspection of a PDF cannot distinguish a high-quality AI fake from a genuine document. Calling back the issuing institution does not scale.

Closing: The issuing institution's regulated electronic seal binds the credential to the institution's verified legal identity. Verification against official trust anchors such as the EU Trusted List or the Swiss Trusted List transforms the authenticity check from a subjective human assessment into a deterministic cryptographic verification process.

Limits: Anyone who does not verify the credential is not protected. The protection works only if recipient-side verification is built into the business process. An HR department that reviews diplomas purely visually does not benefit from sealed diplomas either. The architecture of the verification step is therefore just as important as the sealing itself.

3. How a Signature Actually Comes to Be: the Process in Five Steps

A signature passes through five steps from document creation to verification at the recipient's end. Understanding the sequence allows a clear argument about which trust anchor applies at which point and how best to integrate it into the architecture.

The same principle applies, mutatis mutandis, to seals, except that there the identity of an organisation is bound rather than a natural person.

Step 0 (once only): Identification of the Signatory

Before someone can use a QES at all, they must identify themselves to the Trust Service Provider. This is not a step in every signing operation but a one-time barrier before first use, comparable to opening an account. The TSP checks the person against a government-issued identity document, typically via video identification, via automatic smartphone identification (based on ETSI TS 119 461), or in future via the Swiss e-ID. The procedure is audited against a regulatory standard.

Only with an identity verified at the required level can a qualified certificate be issued that binds this verified identity to a private key in the TSP's HSM. This step is the actual lever against AI fraud: synthetic identities and pure image-scan documents fail here. Whoever triggers the key in the later signing operation is demonstrably the person whose identity the TSP formally verified on a one-off basis.

Step 1: Document Is Created

The document originates in the source system: an invoice from the ERP, a contract from the contract lifecycle management system, or a diploma from the campus management system. At this point the document exists as an unsigned file, typically a PDF, alternatively XML or another structured format. The content is final, because any subsequent change would invalidate a signature.

Architecture note: the point of document creation is also the natural point for signature or seal integration. The closer the signature is applied to the creation point, the harder the document becomes to manipulate in transit.

Step 2: Hash Is Calculated

A cryptographic hash of the document is calculated, typically SHA-256. This hash is a unique compact representation of the content. If the document were changed by even a single digit, the hash would yield a completely different value.

With cloud-based services, the document is uploaded to the signature portal for this processing — for example the SwissSign Signature Service Web. With Hash Signing, however, only this hash is transmitted to the Trust Service Provider, not the document itself. The document thereby remains under the control of the issuing organisation.

Step 3: Trust Service Provider Signs the Hash with the Signatory's Private Key

At the TSP, the signatory's private key waits in a certified Hardware Security Module (HSM). Before it is released for the signing operation, the signatory must authenticate with multi-factor authentication that ensures sole control over the private key. This authentication draws on the identification result from Step 0: only the one-time verified person can trigger the key assigned to them. This precisely fulfils the legal requirement for "sole control" over the key.

Only after successful authentication is the document hash signed. The result is a cryptographic value (the "signed hash") that could only have been produced with exactly this key. For a qualified signature, a qualified timestamp is additionally appended, which fixes the signing time in a provable manner. It is precisely this timestamp that Swiss law requires for QES to be equivalent to a handwritten signature.

Step 4: Signature Is Embedded in the Document and Issued

The signed hash is now embedded in the document together with the signatory's certificate and the timestamp data, according to a standardised ETSI profile (for PDF this is PAdES per ETSI EN 319 142, see Section 4).

The document is now signed and can be issued: sent by email, made available in a portal, archived, or otherwise distributed. Importantly, the signature is part of the document and travels with it. Even after repeated forwarding, saving, or printing, it remains verifiable in the PDF reader.

Step 5: Recipient Verifies the Signature

The recipient opens the document in a PDF reader or a dedicated validator (such as the free federal validator). The software automatically performs three checks.

First, the integrity check. The hash of the current document is recalculated and compared with the hash in the signature. If both match, the document has not been changed since signing. If they do not match, the signature is "broken" and the reader displays a clear warning.

Second, the certificate check. The embedded certificate is checked against the official Trust List — the EU Trusted List for eIDAS or the Swiss Trusted List for ZertES. This ensures the certificate was issued by a recognised Trust Service Provider and was valid at the time of signing.

Third, the identity check. The reader displays who signed: for a QES, a natural person with a verified name; for a seal, an organisation with a verified entry in the commercial register or a comparable directory. At this point the circle closes back to Step 0: the recipient can rely on the displayed identity having been formally verified by the TSP.

Verification is binary: all three checks successful, or the signature is invalid. This is precisely the shift described in Section 1: away from "looks authentic", towards "verified against a chain of trust".

What This Means for Longevity

A signature has an expiry date because the underlying certificate will eventually lapse, typically after three years. For a document to remain verifiable in ten or twenty years, the PAdES LTV profile is used. It embeds all necessary validation data directly in the document: the certificate, the revocation lists valid at the time of signing, and qualified timestamps. Verification therefore still works even when the original online services have long ceased to be reachable. For long-term archiving, audits, and future legal disputes, this is the prerequisite for keeping signed documents admissible as evidence.

4. Regulatory Framework for Signatures and Seals

This list is intended for orientation, not as exhaustive. It covers the standards that come up in most architecture and compliance discussions.

• eIDAS 2.0 (Regulation EU 2024/1183): QES legally equivalent to a handwritten signature throughout the EU. New trust service categories including Qualified Electronic Attestation of Attributes. EUDI Wallet mandates for public and regulated sectors by end of 2026.

• ZertES (Switzerland): QES equivalent to a handwritten signature. Key Swiss specificity: Swiss QES requires a qualified timestamp for written-form equivalence, which eIDAS does not explicitly require.

• Gap between the two legal frameworks: No automatic mutual recognition between Swiss QES and EU QES. Negotiations are ongoing. Organisations operating cross-border between Switzerland and the EU must plan for both jurisdictions. SwissSign is certified as a Qualified Trust Service Provider for both.

• FINMA Circular 2016/7: Video and online identification requirements for regulated financial intermediaries. QES can replace certain manual verification steps. Currently under partial revision; the consultation ran until 27 February 2026 and integrates the Swiss e-ID as a new identification pathway.

• ETSI signature profiles: PAdES (ETSI EN 319 142) for PDF, XAdES (ETSI EN 319 132) for XML, CAdES (ETSI EN 319 122) for binary and format-independent signatures. Baseline profiles B-B, B-T, B-LT, B-LTA cover different longevity requirements.

5. Integration: Where Signature Services Actually Connect

Three Deployment Models

Trust Service Providers and signature services broadly offer three models, which differ in terms of confidentiality and integration: cloud-based signature services, integration into your systems, or operation within your own infrastructure.

SwissSign is the only Swiss TSP to offer all three models from a single source and to guarantee the same Swiss sovereignty level across all three. The choice of model with SwissSign therefore follows your network topology, data control requirements, regulatory constraints, and operating model.

• Web Service: Low-barrier entry point for occasional or low-volume applications, without integration. The organisation uploads PDFs and the signing process runs hosted at SwissSign. More details on the Web Service product page.

• REST API: Fastest time to deploy, hosted in Switzerland. Document processing runs through the SwissSign API as standard. Hash Signing is available as an optional feature for use cases with strict confidentiality requirements where documents must not cross the organisational boundary. More details on the REST API product page.

• On-Premises: SwissSign software runs within the organisational boundary and takes over document processing, workflow, branding, and connection to customer systems. Hash Signing is integral: only the hash is transmitted to the SwissSign trust infrastructure for the signing operation; the document itself never leaves the customer environment. The sovereignty gain lies in full control over documents, metadata, workflows, and audit data. Relevant where strict data residency, network segmentation, or tenant separation apply. More details on the On-Premises product page.

Integration Points in Existing Infrastructure

• ERP and core processes: Signature at the point of document creation, batch sealing for high output volumes such as invoices, statements, or policies. Typical integration via the signature service API from the document generation layer.

• Document management and archive: Signed documents are stored in WORM-compliant archives. PAdES LTV ensures verifiability over decades without dependency on online services.

• Identity and access management: Step-up authentication via existing corporate IdPs (SAML, OIDC), optionally with a mobile second factor. Signing is a step in the IAM flow, not a parallel system.

• SIEM and audit logging: Every signing operation produces an auditable event containing request, authentication, key usage, timestamp, and verification. These events feed into existing SIEM pipelines via Syslog or API.

• Mobile and customer-facing apps: Signature flows are embedded into existing apps via SDK or redirect-based flows. Relevant for banking, insurance, and e-government citizen portals.

Industry-Specific Notes

• Core banking (Avaloq, Temenos, Finnova, FNZ): Integration typically at the document output layer. Deeper analysis in our article on implementation challenges in financial institutions.

• Insurance core systems: Integration at policy generation and claims workflow.

• Public sector document systems: Integration with existing e-government platforms, often as a shared service across cantonal or municipal authorities.

6. Security Architecture Considerations

Six topics a Security Officer will examine.

• Zero-trust alignment: mTLS between components, step-up authentication per signing operation, least-privilege enforcement, micro-segmentation of the signature infrastructure.

• Audit and evidential integrity: Non-repudiable logs for regulatory oversight and forensic investigation. Every signing operation is traceable back to the signatory's authentication. With On-Premises, application-side audit data resides in the customer infrastructure; the cryptographic operations are additionally logged at the TSP.

• Post-quantum readiness: Monitoring of NIST post-quantum standards (FIPS 203 to 205). A migration path exists: the architectural pattern remains valid; only the underlying algorithms change. SwissSign as TSP is responsible for the migration.

7. Reference Deployments in the Swiss Market

PostFinance: Hash Signing API for Credit Card Applications

PostFinance, one of Switzerland's largest financial institutions with around 2.5 million retail and business customers, has integrated SwissSign's qualified electronic signature into the credit card application process. The architecture is based on the Hash Signing API: documents never leave the PostFinance system; only the cryptographic hash is transmitted to the SwissSign service. The signature solution is linked to Bankident PostFinance, so that existing customers can sign a credit card application end-to-end digitally without having to identify themselves again.

"We wanted to use our already verified identities for the e-signature process. What was decisive for us was that the solution did not create additional effort on the customer side through a re-identification step. SwissSign's signature solution made this effortless and enabled a faster and more convenient process for our customers." — Teodoro Pizzino, Customer Journey Owner Credit Cards at PostFinance

• Deployment model: REST API with Hash Signing

• Trust service components: QES, identity connection via Bankident PostFinance

• Business outcome: fully digital credit card process without media breaks, reduced drop-off rate

Canton of Aargau: Canton-Wide Trust Service Platform

In early 2026, the Canton of Aargau commissioned SwissSign to build a central solution for electronic signatures, regulated seals, and qualified timestamps. The procurement was carried out under the joint framework conditions of eOperations Switzerland. The platform will be available to the cantonal administration and connected municipalities. Going forward, official orders and administrative communications can carry an electronic seal confirming authenticity and integrity. Contracts and agreements are signed with QES directly in the browser, and qualified timestamps reliably record the creation or receipt timestamp of documents in digital mailboxes and archives.

• Deployment model: central trust service platform for the canton and connected municipalities

• Trust service components: QES, regulated seals, qualified timestamps

• Application: official orders, agreements, digital mailboxes, long-term archiving

egovpartner / Canton of Zurich: Standard Solution for Municipalities

As part of a central procurement by egovpartner, SwissSign was selected in 2025 as the provider of a standard solution available to all municipalities and cities in the Canton of Zurich. This allows legally binding electronic signatures to be integrated into existing specialist applications or used directly in the browser, without each municipality having to run its own procurement process. Application areas range from permits and contracts through to minutes and internal approvals.

• Deployment model: dependent on the individual municipality's choice

• Trust service components: QES, optionally regulated seals

• Application: single framework procurement, individual activation per municipality

8. Why Now Is the Right Time

• eIDAS 2.0 timeline: By 24 December 2026, all EU member states must make at least one certified EUDI Wallet available to their citizens. A year later, regulated sectors including banks, telecoms, healthcare, and very large online platforms are required to accept the Wallet as an authentication method where users present it. Wallet use itself remains voluntary for citizens. Architectures designed today should anticipate EUDI Wallet acceptance to avoid playing catch-up in 2027.

• E-invoicing mandates: EU ViDA and Germany's phased B2B e-invoicing mandate are entering force in stages. Obligation to receive in Germany since 1 January 2025, obligation to send from 1 January 2027 for companies with turnover above €800,000, from 1 January 2028 for all domestic B2B transactions. The mandate covers the structured format (XRechnung, ZUGFeRD), not the seal. But anyone who wants to make authenticity and integrity provable needs a seal in addition to format compliance. Structured and verifiable invoices thereby move from best practice to competitive advantage.

• Swiss e-ID rollout: With the rollout expected in 2026, the Swiss e-ID will reduce friction in QES issuance and citizen-facing workflows. Architectures designed today should anticipate this integration to avoid retrofitting when the e-ID becomes active.

Frequently Asked Questions

This article reflects the views of SwissSign and does not constitute legal advice.