Self-hosted by you Constrained device sub-CA SCEP & REST enrolment Wi-Fi & VPN profiles
01 / MEET YOUR ENDPOINTS
Different devices. One approach to identity.
Use the enrolment path that fits your platform. Keep the certificate authority and your network configurations in your own hands.
IOS / IPADOS / MACOS
One profile. A trusted connection.
Build a signed configuration profile with CA trust, SCEP enrolment, and your enabled network configurations. Deliver it for installation on the device.
Installed by the user. Configuration profiles do not provide remote MDM control.
WINDOWS / POWERSHELL
Your certificate. In the right store.
Download a device-bound enrolment script. Run it elevated to generate a key and certificate request, enrol over HTTPS, and install the credential and network settings.
Requires an elevated PowerShell session. Settings are applied by running the downloaded script.
ANDROID / PKCS#12
A credential you can carry securely.
Generate a password-protected credential bundle, transfer it securely, and install it on the device. Import VPN profiles into strongSwan and configure EAP-TLS Wi-Fi manually.
User-installed CA trust has Android platform limits. This workflow does not modify the system trust store.
SCEP / REST CLIENTS
A simple path for your own clients.
Use a compatible SCEP client or send a signed PEM certificate request to the enrolment endpoint. Install the issued credential using your endpoint’s own tooling.
Client integration is required. Network configuration and renewal behaviour depend on your client.
02 / A FOUNDATION YOU OWN
Trust each identity. Understand its lifecycle.
Bring everyday device issuance into a focused workspace. Keep your root of trust separate, and your device credentials under your control.
01
An identity for every endpoint.
Issue certificates through SCEP or a simple REST endpoint.
Expiring, revocable tokens pin enrolment to a device name and DNS identity.
02
A smaller trust boundary.
Keep your root separate from everyday device issuance.
A software-keyed RSA sub-CA is constrained to your device DNS namespace.
03
Networks that know your devices.
Use device certificates for EAP-TLS Wi-Fi and IKEv2 VPN.
Build network configurations once, then deliver them through each platform’s supported workflow.
04
A lifecycle you can see.
Track issued certificates, expiry, renewal, and revocation.
Suspend with certificate hold, release a hold, or revoke permanently. Publish status through CRL and OCSP.
05
Access with clear roles.
Give administrators, operators, and auditors the access they need.
Portal sessions, per-account TOTP, backup codes, and an enrolment activity trail.
06
Your stack. Your records.
Run on your infrastructure, with SQLite or optional MariaDB.
Email renewal reminders and optional external syslog bring lifecycle information into your workflow.
Tokens remain usable for their pinned identity until expiry or revocation. Certificate revocation relies on your connected services checking CRL or OCSP. Understand the lifecycle controls.
03 / KNOW YOUR ENDPOINTS
An identity has a history.
See which certificates have been issued, which are nearing expiry, and which have been put on hold or revoked. Follow enrolment and renewal activity in the portal.
Certificate inventory and expiry visibility
Renewal reminders through configured email
An activity trail for issuance and lifecycle events
A dedicated device sub-CA handles routine issuance. Your root CA signs that authority through a separate ceremony, then stays outside the enrolment path.
01
Establish your device authority.
Generate a sub-CA request, have myOwnCA or a suitable CA sign it, and import the certificate and chain. Constrain issuance to your device namespace.
A CLEAR TRUST BOUNDARY02
Choose the enrolment path.
Deliver an Apple profile, run a Windows script, install an Android credential, or connect a compatible SCEP or REST client.
YOUR PLATFORM’S WORKFLOW03
Operate the lifecycle.
Watch expiry and renewal. Publish a certificate hold or revocation when needed. Configure your relying services to check certificate status.
VISIBILITY AND CONTROL
Your root key stays out of device enrolment. myOwnMDM signs with its own software-held sub-CA key. It does not need continuous access to myOwnCA or its signing hardware.
myOwnMDM is in development, with early access by arrangement. No public software release is available yet.
PERSONAL & NONCOMMERCIAL
Evaluate with a clear agreement.
Early-access eligibility, device limits, and genuine noncommercial evaluation terms are agreed individually. Tell us about your home lab, research, or learning environment.
Every commercial deployment, including an early-access business pilot, requires paid terms agreed with EnigmaIS. Share your device count, platforms, and network requirements.
Source is available for inspection. EnigmaIS source modifications and derivative versions are prohibited under both free and paid terms. Normal settings, supported APIs, and deployment configuration remain permitted. Third-party components retain their own licences. Read the policy summary or the EnigmaIS launch policy; full product terms will accompany the first distribution.
07 / A POSSIBLE NEXT CHAPTER
Device identity today. A measured path forward.
FUTURE DIRECTION / CONDITIONAL
Exploring minimal MDM.
A broader management layer is a possible future direction, guided by customer demand and platform/vendor requirements, including the Apple APNs push-certificate and MDM-vendor path.
Remote lock, wipe, application management, and push-based policy control are unavailable today. There is no committed scope or release date for a full MDM layer.
Today, myOwnMDM focuses on device certificates, enrolment, network profile delivery, and certificate lifecycle visibility. Remote lock, wipe, application management, and push-based policy control are not available. A minimal MDM direction is conditional on demand and platform/vendor requirements, with no committed release date.
Do I need myOwnCA to use it?
myOwnCA is the natural companion for signing the device sub-CA through an offline ceremony. Another suitable CA can sign it if its certificate meets the required RSA and device-namespace constraints. A self-issued lab sub-CA is available for testing.
Are enrolment tokens single-use?
No. Tokens are bound to a device identity, expire, and can be revoked. In the current implementation they remain usable for that identity until expiry or revocation; successful enrolment does not consume them. Protect profiles and scripts that contain tokens.
Does revoking a certificate immediately disconnect a device?
myOwnMDM publishes certificate revocation through CRL and OCSP. Wi-Fi, VPN, and other relying services must check that status and enforce their own access policies. Certificate revocation does not revoke an enrolment token; revoke the token separately to stop token-based re-enrolment.
Is early access free for a home lab?
Early-access eligibility, device limits, and genuine noncommercial evaluation terms are agreed individually with EnigmaIS. Every commercial use, including a business pilot, requires paid terms. No public software release is available yet.
Can I inspect, configure, or modify the source?
Supplied source is available for inspection. Normal settings, supported APIs, and deployment configuration remain permitted. EnigmaIS source modifications and derivative versions are prohibited under both free and paid terms. Third-party components retain their own licences.
THE NEXT STEP IS YOURS
Make device trust your own.
Tell us about your endpoints, platforms, and network. Let’s discuss a deployment that fits.
