How iDDM is built and operated, and how to reach us about a vulnerability. Written for the security teams who have to sign off on a management platform.
Each customer organisation is an isolated tenant with its own APNs push certificate, its own encryption keys and its own administrative boundary. A declaration published in one tenant cannot reach a device in another.
Tenant identifiers are checked at the data layer, not only in the application, so a request without a matching tenant context returns nothing.
Signing keys and customer escrow material, including FileVault recovery keys, are held in hardware security modules. Only an isolated signing service can reach them, and every use is logged with the requesting service and the reason.
Platform staff cannot export key material. Recovery of an escrowed key is an authenticated request from a customer administrator, recorded in that tenant's audit log.
We collect the device attributes management needs — identity, OS version, enrolment and compliance state — and nothing more. Apple's framework does not expose device content to a management server, and we do not request optional data we have no use for.
On personally owned devices under Account-driven User Enrolment, the managed scope is limited to managed apps and accounts.
Every declaration change, activation, enrolment event and administrator action is recorded with actor, timestamp and tenant, and is visible in the console's Audit log.
Logs are append-only, retained for [SỐ THÁNG] months and exportable for your own SIEM.
The platform runs in Viettel DC data centres in Vietnam, with segregated networks between the device-facing, console and administrative planes.
Operating systems and dependencies are patched on a [SỐ NGÀY]-day cycle, and critical vulnerabilities are addressed within [SỐ GIỜ] hours of a fix being available.
Report a vulnerability to security@iddm.vn. Our PGP key is published at iddm.vn/pgp.
We acknowledge a report within [SỐ GIỜ] hours, give a first assessment within [SỐ NGÀY] days, and keep you updated until it is closed. Good-faith research that follows this process and avoids customer data will not be met with legal action from us.
On confirming an incident we contain first, then assess scope. Affected customers are notified within [SỐ GIỜ] hours with what we know, what we are doing and what they should do.
A written post-incident report follows within [SỐ NGÀY] days, including root cause and the changes made.
We are working towards [CHỨNG CHỈ ĐANG THEO ĐUỔI]. Penetration tests are run [SỐ LẦN] times a year by [ĐƠN VỊ KIỂM THỬ], and a summary report is available to customers under NDA.