Quick answer: Phase II of India's Digital Personal Data Protection Act takes effect on 13 November 2026. From that date, if you send SMS (or voice) into India on the basis of consent, the consent must come through a Consent Manager — a registered intermediary whose signature on a consent receipt is the proof a person actually agreed. "We self-asserted consent in our CRM" stops holding. Devotel Orbit ships the platform side of this flow ahead of the deadline: you register the Consent Managers your users consent through, post the signed receipts those managers mint, and verify any receipt's signature on demand. The full integration reference is the Consent Management & Receipts docs; this post explains what changed, how the Consent-Manager model works, what Orbit shipped, whether it applies to you, and what to finish before November 13.
What Phase II actually changes
India's DPDP Act was notified in 2023 with a phased rollout; the Consent-Manager mandate is the piece that lands with Phase II on 13 November 2026. Under it, every Data Fiduciary — the DPDP term for the business that decides why and how personal data is processed — whose lawful basis for a send is consent must take that consent through a registered Consent Manager and hold a signed consent receipt for it.
For messaging and calling, this lands on exactly the population that is already DLT-registered. India's TRAI DLT regime made senders register their Principal Entity, headers, and templates on an operator portal before any A2P SMS is delivered. DLT proved the sender exists and the template was approved; DPDP Phase II proves the recipient agreed. The two regimes stack: DLT registration is the sender's identity, the signed consent receipt is the recipient's permission, and a carrier scrub can ask for either. "We always worked this way with DLT" is not an argument — this is a second, independent obligation from a different statute, and the November 13 date applies to every sender whose DLT content templates say consent is the basis.
A plain-language translation of "signed consent receipts, mandatory": starting November 13, consent for messaging into India has to be provable in a format a regulator accepts — an independent party's signature on a structured, tamper-evident record, not a boolean in your CRM.
How the Consent-Manager model works, in business terms
DPDP borrows the regulated-intermediary pattern from India's account-aggregator framework and applies it to consent. Five ideas, in order.
A Consent Manager is a licensed middle party. It holds no messaging inventory and sends nothing. Its only job is to present a clear, itemised consent request to an individual, capture the yes, and record it so neither the sender nor the regulator has to take the sender's word for it. You pick one — typically the consent platform your customers' devices already integrate, or the one your DLT operator points to. Anyone a user consents through just has to be registered with Orbit before its receipts will pass verification.
The consent artefact is a receipt. Instead of "user 123 opted in at some point," the Consent Manager mints a receipt with the consent's own ID, the subject's identifier, the purpose, the scope of permitted processing, the timestamp, and the Consent Manager's identity. That receipt is the artefact your compliance checklist, a carrier scrub, or a Data Protection Board inquiry will ask for. "We had a checkbox once" is not an audit artefact.
The signature is the whole point. The Consent Manager signs the receipt with ECDSA P-256 (the NIST P-256 elliptic curve) over SHA-256, format standardised by the Data Protection Board of India. ECDSA-P-256 is used as proof and as revocation: proof, because forging the signature is computationally infeasible without the manager's private key; revocation, because a manager can sign a withdrawal too, and an unsigned "the user unsubscribed" from the sender no longer counts. Verification is standard public-key cryptography — anyone who holds the manager's published public key recomputes the hash and asks whether the signature matches, without calling the manager.
Canonicalisation makes receipts comparable. Two equivalent receipt payloads with keys in different orders would hash differently and fail verification against each other, so the receipts you hold are byte-stable regardless of intermediate serializers. This is why "we stored the consent payload but can't prove what was signed" fails as an audit answer.
You no longer point to your own database when challenged. A regulator, an auditor, or a DLT operator asks "show recipient X's consent for purpose Y," and you return a signed receipt from a registered manager that a third party can verify. That is what "compliance with Phase II" looks like at the sender level.
What Orbit ships for it
Orbit's role is to make the consent receipts you collect verifiable and durable at the platform level. The shipped surface, registered under the API's /compliance prefix, is small and deliberately so:
POST /consent/managers— register a Consent Manager, keyed on its public-key bundle (admin).POST /consent/receipts— persist a signed receipt; Orbit runs one verification at intake and rejects invalid ones.POST /consent/receipts/:id/verify— re-verify any stored receipt on demand, e.g. when a scrub or audit asks.
A worked sequence looks like: your backend registers "the manager our customers consent through" once, with the manager's public certificate; as users consent, you forward each minted receipt to POST /consent/receipts, which is rejected if the signature does not verify; months later, an auditor cites a receipt ID and POST /consent/receipts/:id/verify confirms both its integrity and its provenance. The consent itself still hangs off your contacts and purposes — Orbit does not decide what constitutes a lawful purpose for your business — but the evidentiary chain can be demonstrated against a signature rather than asserted from a row in your database.
Two of the route family are flagged for clarity:
- Verification is fail-closed. A receipt whose signature does not match, whose issuing manager is not registered, or whose payload no longer matches the persisted canonical form is rejected with a 422 before it is stored. Orbit would rather drop a bad receipt at the boundary than persist it and discover the discrepancy during an audit.
- Registered managers are mandatory, but names are not policed. Orbit verifies you registered a manager and that the resolution of
manager_id → public keymatches the signature. Whether "the ID your customers use in their consent UI" iscm-acme-prodor a reverse-DNS identifier is between you and that Consent Manager.
The full walkthrough — payload floor, the signature-form expectations, manager deactivation semantics — is in the Consent Management & Receipts docs. The DLT side of the same operator-country story — entity and template registration, the scrub that runs against them, the four DLT state filters — is the DLT-India Onboarding docs. Phase II's template-stack of "this template is promotional and needs consent receipts" is exactly the classification the DLT scrub already records for your headers.
Who is affected, and what to do before 13 November 2026
Affected, in practical terms:
- Every DLT-registered sender into India relying on consent as the lawful basis for a send — which is most A2P marketing, re-engagement, and re-permission traffic.
- Your CPaaS tenant, if it sends into India and your basis column for a contact says consent. If your basis is transaction/service, Phase II does not manufacture a consent obligation, but it also does not retroactively make a transactional basis stick for marketing traffic.
- Anyone whose post-scrub audit artefact is currently "consent flag in the CRM." On 13 November that artefact stops carrying weight; from that date it either points to a signed receipt or it stands as unconsented.
What to do in the next few weeks, in order — the surface is small enough that most tenants finish it in less than a sprint:
- Inventory which of your DLT content templates say consent is the lawful basis (promotional category does this by definition in DLT terms). If that set is non-empty, Phase II applies to you.
- Pick a registered Consent Manager and get its public-key bundle. This is the selection DPDP makes mandatory; Orbit's surface is not a substitute for picking one.
- Register that manager on Orbit through
POST /consent/managers. One call per manager, admin role required. - Start forwarding receipts from that manager into
POST /consent/receiptsas they are minted, so the pipeline is proven before the deadline rather than first exercised the morning of the 13th. - When a DLT scrub or an audit asks for consent provenance, cite receipts by ID and re-verify them through
POST /consent/receipts/:id/verify— the endpoint exists so a re-run of verification is a compounding-free operation. - If you are not yet DLT-registered, schedule that separately through the existing DLT checklist; Phase II presupposes DLT, it does not replace it.
Tenant-owned responsibility, framed the way Orbit frames every compliance surface
Registering and verifying are platform surfaces. Registering managers, taking consent through them, choosing what purposes count, and answering audits are tenant-owned responsibilities — the same split as every other Orbit compliance control. Orbit provides the verification boundary, the persistence, and the audit-replay endpoint; the tenant owns which Consent Managers it trusts, what its own users consented to, and what a lawful basis looks like for its traffic. Naming a purpose in a consent template does not move that responsibility to the platform. This framing exists so procurement and your legal counsel can read one paragraph and know exactly where platform responsibility ends and tenant responsibility begins.
Frequently asked questions
Does this mean Phase II applies to all senders?
No — it applies to senders whose lawful basis for a send is consent, and who process personal data of individuals in India. Pure transactional flows (order confirmations, OTPs) ride on a different basis and are outside the Consent-Manager mandate; the mandate binds when consent is what you claimed.
Which date is the Phase II effective date?
13 November 2026. That is the enforcement date for the Consent-Manager mandate; ancillary DPDP provisions already run under earlier phases.
What is a Consent Manager in plain terms?
A licensed intermediary that presents a defined consent request to a person, captures the yes, signs a tamper-evident receipt as proof, and registers the signature with a public certificate. It sends no traffic itself; it exists so the sender can prove consent later without self-asserting it.
What does Orbit actually verify?
Two things: that the issuing manager of an inbound receipt was registered on your tenant, and that the ECDSA-P-256 signature over the receipt's canonical payload verifies against the manager's registered public certificate. Invalid receipts are rejected at intake; stored receipts can be re-verified on the audit path.
Does Orbit require that I use the receipts for my sends?
Orbit provides and verifies the surface; which of your sends a regulator will ask about is decided by your DLT template classifications and your own stated lawful basis. Registration of managers and receipts is tenant-initiated.
Where is the integration reference?
The Consent Management & Receipts docs carry the payload floor, the manager lifecycle, and the error taxonomy. DLT-India Onboarding documents the sender-side DLT scrub that determines which of your templates even claim a consent basis.