By David,
Plenty of signature vendors describe themselves as Azure-something - hosted on Azure, integrated with Azure, certified for Azure. Almost all of them mean: our multi-tenant SaaS runs on Azure infrastructure we rent. That's a hosting choice, and it changes nothing for you as a customer. Your data still lives in their environment; your mail may still route through their service; their bill still arrives on their letterhead.
"Azure-native" is worth reclaiming, because there's a version of it that's structural rather than cosmetic - and the difference shows up in three places every IT leader actually feels: procurement, security review, and operations.
What structural Azure-native looks like
Atlas Ink is Azure-native in four specific, verifiable ways:
1. It deploys into your subscription. Installing Atlas Ink doesn't provision you a login to someone else's platform - it deploys the platform itself into your own Azure subscription: your App Service, your per-tenant PostgreSQL database, your Key Vault holding the encryption keys. The vendor-hosted environment that most signature reviews spend their time on simply doesn't exist. (Why that matters for risk is its own article.)
2. Identity is Entra ID, end to end. There's no parallel user database to enroll people into and no sync job copying your directory to a vendor. Signatures are directory-driven at the source: templates carry tokens - name, job title, department, phone, office - that hydrate per user from Microsoft Entra ID at push time, read through Graph, read-only. Fix a title in Entra and the next push publishes it everywhere.
3. Mail integration is the admin API, not the mail path. Atlas writes each user's own Outlook compose signature through the Exchange admin API. It never routes a message through Atlas - no connectors and, by default, no transport rules and no in-transit stamping. (Optional server-side stamping, which an admin turns on explicitly, adds one mail-flow rule in your own Exchange Online - Microsoft's pipeline, never a vendor hop.) That single choice is what keeps the product out of scope for mail-flow compliance review, and it's only possible because the product is built against Microsoft's own management surfaces rather than bolted onto the SMTP path.
4. Billing is simple prepaid units. Usage is billed via Stripe - $1 per active user, per month, always, counting only users whose mailbox actually carried a managed signature that month. No seat minimums, no annual commitment.
Where the difference lands
Procurement. A new SaaS vendor means security questionnaires, a DPA, and a seat-licensed renewal to track. Atlas Ink deploys into your own subscription - so the security review is lighter, and no signature content leaves your tenant (only usage counts and, for any clickable banners, the banner links and their click counts reach Atlas) - while units are a small prepaid charge billed via Stripe, with no seat commitment and no annual renewal. The four-month procurement cycle collapses into an afternoon.
Security review. The review scales with what the vendor holds. A hosted signature SaaS holds your directory copy and possibly your mail in transit; reviewing it properly is real work, renewed annually. With an in-subscription deployment there is no vendor environment to assess - the service runs inside the boundary your existing Azure governance, logging, and conditional-access policies already cover. Your SIEM watches it like any other resource, because it is any other resource.
Operations. The unglamorous wins compound: the platform's logs are in your Log Analytics, not behind a vendor support ticket. Its availability is your App Service's availability, visible on dashboards you already run. Backup, network rules, and private endpoints follow whatever standards your subscription already enforces. Nothing about it is special, and in operations, "nothing special" is the highest compliment there is.
Where it runs, and what it works with
Two clarifications, so "Azure-native" means exactly what it says:
- Commercial Azure today. Atlas Ink deploys into your own Azure subscription and is metered per active user, billed via Stripe. Azure Government and GCC High are on the roadmap - the product deliberately fails closed for sovereign clouds rather than run unvalidated, and we've written plainly about where that stands.
- Native means out of the mail path. Because Atlas, by default, pushes the mailbox compose signature instead of stamping in transit, nothing new sits between your users and their recipients. If you also keep a disclaimer on system-generated mail, Exchange's own transport rules coexist happily with pushed signatures.
The two-question test
Next time a vendor says "Azure-native," ask: whose subscription does it run in, and whose invoice does it bill to? If the answers are "ours" and "ours," you've found a hosting choice wearing a badge. If the answers are "yours" and "yours," the architecture actually changed - procurement gets shorter, review gets smaller, and operations get boring in the best way.
Atlas Ink answers "yours" to both, from deployment to the meter. That's the whole point.