Built like a certificate authority should be.

01

Architecture & data flow

The service runs entirely in Microsoft Azure — European Union (West Europe, Netherlands) or United States, chosen by you when you activate — operated by a service provider established in the European Union. Nothing is deployed inside your network.

Customer data stays in the region you chose — EU/EEA or United States — except where Microsoft's global services (Entra ID sign-in, the commercial marketplace) require otherwise under Microsoft's standard safeguards.

02

Shared responsibility

A managed CA removes servers, patching and key custody from your plate. Some decisions stay with you by design.

03

Encryption & key management

1. 01

   CA private keys

   Generated inside Azure Key Vault Premium HSMs (FIPS 140-2 validated) and non-exportable. Every signature — certificate, CRL, OCSP response, SSH certificate — is computed inside the HSM. Deleting a CA deletes its key, subject to Key Vault soft-delete.

2. 02

   Certificate private keys

   Never in our possession. Devices and ACME clients generate them locally; Key Vault issuance keeps them in your vault, which we only ask for a certificate signing request.

3. 03

   Entra app credentials

   Managed app credentials are certificates whose keys live in your Key Vault. We publish only the public certificate to the app registration through Microsoft Graph and rotate it automatically with a grace period.

4. 04

   In transit

   TLS 1.2+ on the portal, API and OCSP. CRL and AIA objects are additionally served over plain HTTP because the PKI standards require it — they contain only signed, public data.

5. 05

   At rest

   Azure SQL, Storage and Key Vault are encrypted at rest by Azure with Microsoft-managed keys.

04

Identity & access

1. 01

   Entra ID only

   There are no local accounts and no passwords stored by the service. Your tenant's MFA and Conditional Access policies apply automatically to every sign-in.

2. 02

   Least privilege, per subscription

   PKI administrators are users (by UPN), Entra groups or service principals you designate. Ordinary users see only their own certificates and the self-service options you open for them.

3. 03

   Guard rails

   An administrator cannot remove themselves, the last administrator cannot be removed, and every permission change is written to the audit log and can trigger an invitation e-mail.

4. 04

   Domain ownership & approval

   Decide per CA who may request certificates for which DNS names — enforced identically across the portal, the API and ACME.

5. 05

   Tenant isolation

   Every customer is isolated by Entra tenant id. Requests are authorised against the caller's tenant on every API call; there is no cross-tenant data path.

6. 06

   Operator access

   Access to production is limited to named individuals with MFA, uses Azure RBAC and is recorded in the Azure activity log.

05

Secrets management

1. 01

   The API authenticates to Azure SQL, Key Vault and Storage with a managed identity — there are no connection strings with passwords and no keys on disks.

2. 02

   Customer integration secrets (for example the Intune validation client secret) and platform secrets are stored in Key Vault, never in the database, and are rotated on a schedule.

3. 03

   SCEP static challenges are stored only as salted hashes; the clear value is shown once at creation. ACME External Account Binding keys are shown once at CA creation.

4. 04

   Private keys of issued certificates, PFX passwords and recovery material are never logged or persisted by the service.

06

Logging, audit & traceability

1. 01

   Append-only audit log

   Every issuance, revocation, CRL or KRL publication, CA, template, domain and permission change is recorded with actor, time and details. Event codes mirror Windows ADCS where an equivalent exists (4887 issued, 4870 revoked, 4872 CRL published).

2. 02

   SIEM export

   Audit events stream exactly once, in order, to Azure Log Analytics / Microsoft Sentinel, Splunk HTTP Event Collector or a generic webhook.

3. 03

   Monitoring

   Service health, errors and performance are monitored with Application Insights. Issuance throughput and per-plan rate limits are measured and published, not estimated.

4. 04

   Abuse protection

   Anonymous protocol endpoints (SCEP, ACME, OCSP) carry per-client rate limits so one runaway client cannot affect other tenants.

07

Availability, backup & disaster recovery

1. 01

   Today

   Each regional deployment (EU: West Europe; US: Azure US regions) runs in one Azure region with Always On compute. Azure SQL provides automated backups with point-in-time restore; CA certificates, CRLs and SSH KRLs are published to Azure Storage so relying parties keep validating even if the API is briefly unavailable.

2. 02

   Roadmap

   Zone-redundant compute and database, then a warm standby region per geography (EU and US). When that tier ships we will publish a contractual SLA with a 99.9% monthly availability target.

3. 03

   No signed SLA yet

   Until then we share measured uptime on request and do not claim a signed SLA. We would rather tell you this here than in a contract negotiation.

4. 04

   Zero-outage CA renewal

   A CA certificate can be renewed with the same key, so existing certificates, chains and CRLs keep validating — nothing to redistribute to devices.

08

Incident response & vulnerability disclosure

1. 01

   Reporting

   Report security issues to security@radius365.org. We acknowledge reports within 2 business days, keep you informed while we investigate, and credit researchers who want it. Our machine-readable contact is published at portal.radius365.org/.well-known/security.txt.

2. 02

   Safe harbour

   We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to fix an issue before disclosure.

3. 03

   Customer notification

   If an incident affects your data or the trustworthiness of your CAs, we notify the subscription's administrators without undue delay — and within 72 hours of becoming aware for incidents involving personal data.

4. 04

   CA compromise

   Because CA keys cannot leave the HSM, the realistic failure modes are mis-issuance or platform compromise. The response is revocation, CRL/OCSP republication and, if needed, CA re-keying coordinated with you.

09

What data we process, and where

1. 01

   Identity data

   Your Entra tenant id, and the user principal names and object ids of the administrators and requesters who use the service. No passwords, no directory synchronisation.

2. 02

   Certificate data

   Issued certificates (public objects), their subjects and names, revocation status, templates and domain registrations — the records a certificate authority must keep to publish revocation information.

3. 03

   Audit and telemetry

   The audit log described above, plus request logs and performance telemetry used to operate the service.

4. 04

   Location and retention

   Everything is stored in the data region you chose at activation — Azure West Europe (Netherlands) for EU organisations, Azure US regions for US organisations. Certificates, revocation status and audit records are kept for the life of the subscription and for 12 months after it ends, so revocation information stays available to relying parties; telemetry is retained 30–90 days. CA keys are deleted from Key Vault when a CA is deleted.

10

Subprocessors

We do not sell data and use no advertising or third-party analytics trackers — on the product or on this website.