By David,
Let's clear the vendor-marketing fog first: no email signature product is "CMMC certified," including ours. CMMC assesses your organization's implementation of its controls across your boundary. A tool can make that boundary easier or harder to defend - that's the entire, honest scope of what a vendor can claim. What follows is the architectural argument, which is the only argument that should move you.
Why signature tools are a boundary problem
CMMC's center of gravity is controlled unclassified information (CUI) and the systems that store, process, or transmit it. For most defense contractors, email is squarely in scope - CUI moves through it - which means everything that touches your mail or the systems around it is a scoping conversation.
Now look at how mainstream signature platforms work mechanically:
- In-transit stampers route outbound mail through the vendor's cloud, where the signature is applied. If CUI-bearing mail transits that service, you've extended CUI processing to a third party's commercial environment - and your assessment now has to account for it: flow-down, documentation, and an external service provider conversation you didn't need.
- Directory-sync platforms copy user attributes - names, titles, org structure, phone numbers - into vendor databases to render templates. That's organizational data about cleared and uncleared personnel resting outside your boundary, on someone else's retention schedule.
- Client add-ins phone home to vendor services for templates and data - lighter, but still an external dependency woven into every workstation in scope.
None of this makes those products wrong for commercial customers. It makes them expensive at assessment time for you, because every added flow is scoping work, SSP documentation, and assessor questions - purchased alongside a signature tool.
The architecture that keeps the boundary small
Work backwards from what an assessor traces and the desirable shape falls out. Mail must not gain a third-party hop, so the signature must be applied in the mailbox - written as the user's own Outlook compose signature - never stamped in transit. Directory data must not leave, so tokens must hydrate from Entra ID in place, read-only, with no vendor-side copy. And the platform itself should introduce no vendor-operated environment at all, which means it deploys into your own subscription, inside the boundary you already defend.
That's Atlas Ink's design, precisely: your App Service, your per-tenant PostgreSQL database, your Key Vault keys; Entra read-only at push time; each user's compose signature written via the Exchange admin API; no transport rule by default, and no mail ever routed through Atlas. The one opt-in exception, server-side stamping through a mail-flow rule in your own Exchange Online, isn't available in GCC or GCC High - so in the enclaves where CUI usually lives, the push-only posture isn't a setting you have to police. No signature content leaves your tenant: Atlas receives an aggregate monthly active-user count for metered billing via Stripe and, if you add clickable banners, the banner links and their click counts. When the assessor asks "what does this tool add to the boundary?", the answer is: one more resource group inside it, and billing and banner-click counts leaving it.
We call this CMMC-aligned architecture and we police our own language about it: aligned means designed to fit inside an assessed boundary rather than expand it - it does not mean certified, validated, or "ready," and any vendor using those words about a signature product deserves your skepticism.
The honest scoping notes
Three boundaries of our own, stated plainly, because contractors can smell an overclaim:
- Commercial Azure today. Atlas Ink deploys into your own Azure subscription and is metered per active user, billed via Stripe. If your enclave is GCC High or Azure Government, read the roadmap piece - validation there is planned, the product fails closed in sovereign clouds rather than run unproven, and pricing will match commercial - the same metered $1 per active user - when it ships.
- Provisioning covers composed mail. Pushed signatures appear on what users compose with the mailbox signature. If a contract or policy requires unremovable marking language on every message from every source, that layer belongs to Exchange transport rules - Microsoft-run, already inside your boundary - alongside pushed signatures for humans.
- The tool doesn't do the paperwork. In-boundary deployment removes flows an assessor would otherwise trace; your team still documents the resource group, its access controls, and its data flows in the SSP like any other in-boundary system. It's a smaller job, not a skipped one.
Where to go deeper
The step-by-step build - directory hygiene, template and scoping decisions, enforcement, and the evidence trail an assessor will actually ask for - is its own article: How to Build a CMMC-Ready Email Signature Solution. The wider public-sector picture, including procurement, is on the government industry page and in the government buyer's guide.
The one-line summary for your next scoping meeting: signature management is available as an in-boundary capability rather than an external service - so the assessment conversation about it is one paragraph, not one section.