Legal departments handle contracts, evidence files, and other highly confidential documents. The common workflow of uploading a PDF to a cloud‑based sharing service instantly creates a security risk: the file lives outside your corporate perimeter, and you lose granular control over who can view it and for how long.

What if you could embed a secure, encrypted PDF viewer directly into your .NET web portal, guaranteeing that the document never touches a third‑party server?

In this guide we walk through a practical architecture built around Doconut Viewer, the .NET document viewer SDK. It is installed into your own application and makes no calls to Doconut servers, so the document never leaves your infrastructure.

Two things to be clear about before the first step, because the rest of the guide depends on them. Doconut.app is the free web viewer — a website, not a component, and not what you install here. And the encryption, the tokens and the audit log below are yours to build: the SDK renders documents, it does not ship a compliance programme. Doconut holds no ISO 27001 certificate, no SOC 2 report and no HIPAA attestation, so the compliance argument you can actually make to a regulator is architectural — the file stayed inside a boundary you already control.

Risk	Typical Cloud Service	What this architecture does instead
Data exile - file stored on external servers	Files are persisted on the provider's storage, often in regions you cannot control.	The PDF stays on your own infrastructure. The SDK renders it there and calls nobody.
Loss of control over access lifetimes	Sharing links can be forwarded indefinitely.	You issue short-lived, single-use tokens. This is code you write, not a switch you flip.
Compliance gaps	Auditing logs are often limited to "download" events.	You log every preview request, because the request goes to your own endpoint.
Plugin dependence	Many viewers require Flash, ActiveX, or browser extensions.	Nothing is installed on the reader's machine; the browser receives rendered pages.

Solution Overview

Install Doconut Viewer into your .NET project.
Encrypt PDFs at rest with a server-side key, using .NET's own cryptography.
Embed the viewer in a Razor page or MVC view, behind a token your application issues.
Log every preview request for audit trails and anomaly detection.

Steps 2, 3 and 4 are your application's work. The SDK's part is step 1 and the rendering; everything protective in this design is code you own, which is also why it can be audited by your own team.

Below is a detailed walkthrough of each step, including best‑practice recommendations for key management, token security, and compliance logging.

Step 1 – Prepare Your .NET Environment

Open your solution in Visual Studio (2022 or later recommended).
Pick your target framework. Doconut Viewer supports ASP.NET, MVC, .NET Core, .NET 6+ and Blazor. Record the version you settle on — the integration details are version-specific.
Install the SDK from the Doconut download page, using the package and documentation that match the version you selected. Take the package name and the setup steps from that documentation rather than from an article; both have changed across releases.

Keep the licence configuration out of source control while you are there. It is the single most common thing to leak from a working prototype.

Additional Tips

Store the package reference in a Directory.Packages.props file for centralized version management across multiple services.

Step 2 – Store PDFs with Strong Encryption

2.1 Choose an Encryption Algorithm

This is your decision and your code. System.Security.Cryptography in .NET gives you AES-256-GCM, which provides authenticated encryption — confidentiality and integrity together — and is a defensible default for documents at rest.

No encryption algorithm makes a system compliant with GDPR, HIPAA or ISO 27001. Those frameworks ask about processes, access control, retention and evidence. Encryption is one control among many, and a viewer library cannot supply the rest.

2.2 Implement Secure Key Management

Never hard-code keys. Use Azure Key Vault, AWS KMS, or HashiCorp Vault to retrieve the encryption key at runtime.
Rotate keys regularly — every 90 days is a common practice. Plan the re-encryption job before you need it; discovering you have no way to roll a key is a bad thing to learn during an incident.

Step 3 – Generate a Time‑Bound, One‑Use Token

The preview token acts like a single‑use badge that expires automatically. It embeds:

User ID – Who is allowed to view the document.
PDF ID – Which encrypted file to stream.
Expiration – Usually 5–10 minutes, configurable per policy.
Signature – HMAC or RSA signed to prevent tampering.

3.1 Security Considerations

TLS everywhere – Always serve the token over HTTPS.
Least privilege – Encode only the data required for preview; avoid embedding extra claims.
Token revocation – A simple “blacklist” in Redis allows immediate revocation if a user’s access rights change.

Step 4 – Embed the DoconutApp Viewer

4.1 Server-Side Streaming Endpoint

Decrypt in memory if your threat model calls for it, so the plaintext never lands on disk. This is your endpoint, so it is your choice to make and your code to review.
Rendering happens on your server, not in the reader's browser. That is what lets the browser display the document without ever receiving the source file — and it is also the reason to check where the SDK writes temporary render output, and what removes it.

4.2 No Plugins Required

The reader gets rendered pages over standard web technologies, so the viewer works across Chrome, Edge, Firefox and Safari with no plugin, ActiveX control or Flash dependency. Nothing is installed on a lawyer's laptop, which is usually the difference between a security review that finishes and one that does not.

Step 5 – Audit & Log Access for Compliance

Legal teams often need a tamper‑evident trail of who viewed which contract and when. Implement a structured logging pipeline:

Field	Description
`UserId`	Identifier of the requesting legal professional
`PdfId`	Internal reference to the encrypted document
`Timestamp`	UTC time of the preview request
`IpAddress`	Source IP (helpful for geo‑location checks)
`UserAgent`	Browser string for forensic analysis
`Result`	Success / Failure (e.g., token invalid, decryption error)

Best Practices

Store logs in an append‑only, immutable datastore (e.g., Azure Log Analytics, Splunk, or a write‑once S3 bucket).
Enable alerting for abnormal patterns—such as the same token used from two distinct IPs within seconds.
Retention policy: Keep logs for the period required by your jurisdiction (commonly 7 years for legal records).

Quick Recap

Install Doconut Viewer into your .NET project, using the documentation for your version.
Encrypt PDFs on write with AES-256-GCM from .NET's own cryptography library; manage keys via a vault service.
Issue a short-lived, single-use preview token when a user requests a view.
Render on your server and embed the viewer in a Razor page. The document never goes to a third party, and nothing is installed on the reader's machine.
Log every preview for auditability, with alerting for suspicious patterns.

Points 2, 3 and 5 are your code. That is the honest division of labour, and it is worth stating plainly in your own security documentation, because a reviewer will eventually ask which party is responsible for what.

Conclusion

Secure PDF sharing does not have to involve a third-party service. With Doconut Viewer inside your own .NET portal, your legal department can present confidential contracts, litigation exhibits and internal policies without the file ever leaving your infrastructure.

What the SDK gives you is that last part: rendering, in your environment, with no call home. The end-to-end encryption, the access control and the audit trail are yours — which is the point, because a viewer that claimed to provide them would be asking you to trust a vendor's compliance instead of your own.

Ready to try it? Visit doconut.com — the trial licence is free, and the live demos are the quickest way to see whether the rendering holds up on your worst exhibit before you write any of the code above.

Implementing these steps will give compliance officers peace of mind, reduce the attack surface, and keep your PDFs firmly inside your corporate firewall—exactly the security posture any legal team needs.

Stay secure, stay compliant, and keep those sealed envelopes where they belong: inside your own vault.

Why Traditional Cloud Sharing Falls Short