Zero Publisher Access: Why We Built VaultGuard360 With No Access to Your Deployment

When you install an Azure Managed Application from the marketplace, there's a detail buried in the deployment model that most customers never think about: the publisher's access level to your managed resource group.

By default, most publishers configure themselves with Contributor access. That means the publisher — the company that built the application — can see, modify, and potentially delete the resources running inside your tenant. It's the standard model. Microsoft designed it this way so publishers can provide support, push updates, and troubleshoot issues remotely.

VaultGuard360 doesn't work that way. We configured our Partner Center listing with "No access" — meaning Sentinel Vault Systems has zero visibility into your deployment. We can't see your resources, we can't read your data, and we can't modify anything.

This was a deliberate architectural decision, and it's worth explaining why.

How Azure Managed Applications Typically Work

To understand why our approach is different, let's look at the standard Azure Managed Application model.

When a customer deploys a Managed Application, Azure creates two resource groups:

1. The application resource group — owned and controlled by the customer
2. The managed resource group — contains the actual application resources (VMs, storage accounts, databases, etc.)

In the standard model, the publisher gets a role assignment (typically Contributor or Owner) on the managed resource group. This gives them the ability to:

• View all resources and their configurations
• Read data stored in those resources
• Modify resource settings
• Deploy updates directly
• In some cases, delete and recreate resources

For many SaaS-style applications, this makes sense. The publisher needs access to manage the infrastructure, push patches, and provide hands-on support.

But for a security monitoring tool that has read access to your Key Vaults? That's a different story entirely.

Why Publisher Access Is a Problem for Security Tools

VaultGuard360 monitors your Azure Key Vaults. It reads secret metadata, certificate expiration dates, and key configurations. By design, it needs read access to sensitive infrastructure.

If we also had publisher-level access to the managed resource group, that would mean:

• We could see the Function App's configuration, including any connection strings or environment variables
• We could view Application Insights telemetry, which might contain metadata about your Key Vault contents
• We could modify the application's behavior by changing configurations or deploying new code
• We could access the storage account where scan results and alert history are kept

In short, publisher access to a security tool's managed resource group creates a transitive trust problem. You'd be trusting VaultGuard360 to monitor your secrets while also trusting us not to look at the data it collects. That's an uncomfortable amount of trust to ask for.

What "No Access" Actually Means

When we set VaultGuard360's publisher access to "No access" in Azure Partner Center, it means:

• No role assignment is created for Sentinel Vault Systems on the managed resource group
• We cannot authenticate to any resource in your deployment
• Azure Activity Log will show no sign-ins from our tenant to your resources
• We cannot push updates directly to your deployment — updates go through the Azure Marketplace update flow, which you control
• We have no support backdoor — if you need help troubleshooting, you share information with us; we can't pull it ourselves

This is the most restrictive publisher access level Azure offers. It means we treat your deployment the same way we'd treat any other customer's infrastructure — as something we have absolutely no right to access.

How to Verify This Yourself

We don't expect you to take our word for it. Azure gives you the tools to verify publisher access independently.

Check the Managed Application's authorization

1. Navigate to your managed resource group in the Azure portal
2. Open Access control (IAM)
3. Click Role assignments
4. Look for any role assignments from an external tenant

With VaultGuard360, you won't find any. There is no role assignment for Sentinel Vault Systems or any of our service principals.

Review Azure Activity Log

1. Open the Activity Log for the managed resource group
2. Filter by time range and look for any operations initiated by external identities
3. You should see only operations from your own tenant's identities and Azure's internal platform operations

No sign-ins, no read operations, no modifications from our side. Ever.

Inspect the Managed Application definition

1. Navigate to the Managed Application resource in your application resource group
2. Look at the Authorizations section in the application's properties
3. Compare with other Managed Applications you've deployed — you'll likely see that others list publisher principal IDs with Contributor or Owner roles

This kind of transparency matters. If a vendor tells you they can't access your data, you should be able to prove it.

The Tradeoffs We Accepted

Choosing "No access" isn't free. We gave up several conveniences that publishers with Contributor access enjoy:

No remote troubleshooting

When a customer reports an issue, we can't SSH into a VM or pull logs from Application Insights. We have to guide customers through diagnostic steps or ask them to share logs. This makes support harder, but it's the right tradeoff for a security product.

No direct updates

We can't push hotfixes directly to your deployment. Updates go through the Azure Marketplace managed application update process. This is slower, but it means you always have visibility into what's changing and when.

No proactive monitoring of deployments

Some publishers monitor their customers' deployments to catch issues before customers notice. We can't do that. Instead, VaultGuard360 includes built-in health checks and self-diagnostics that surface issues through the product itself.

Every one of these tradeoffs makes our lives as a publisher more difficult. But they make your deployment more secure, and for a security tool, that's the only calculus that matters.

Why This Should Be the Standard for Security Tools

We think any security-focused Azure Managed Application should default to "No access." If a product is designed to monitor, protect, or audit your infrastructure, the publisher having backdoor access to that product's deployment undermines the entire value proposition.

It's like hiring a security guard who insists on keeping a copy of your house key. Maybe they'll never misuse it. But why would you accept that risk when a better option exists?

The Azure Managed Application framework gives publishers the choice. We chose the option that puts customer trust above publisher convenience. We'd encourage other security vendors to do the same.

Trust, But Verify

Zero publisher access isn't just a feature we list on a marketing page. It's a verifiable, auditable architectural decision baked into how VaultGuard360 is distributed through the Azure Marketplace.

You can check it yourself in three minutes using the steps above. If you find a role assignment from our tenant, that's a bug, and we want to know about it.

Security tools should earn trust through transparency, not ask for it through fine print.

---

Want a Key Vault monitoring solution that runs entirely in your tenant with zero publisher access? Explore VaultGuard360 or contact us to learn more about our security architecture.