Digital Identity (DID) Architectures for Enterprise Access Control

Your access control is buckling under today’s mandates

You’ve likely seen at least one of these while flying:

These days, phishing-resistant MFA is really essential. Thanks to OMB M‑22‑09 and guidance from CISA, both agencies and vendors are being encouraged to adopt FIDO2/passkeys and device-bound authenticators. On top of that, big identity providers are now making MFA a default requirement for admin accounts. The old-school SMS and app-code MFA methods are gradually being retired for users that need extra protection. (idmanagement.gov)
The wallet revolution is in full swing! With eIDAS 2.0 on the scene, all EU Member States need to roll out EUDI wallets that work across borders by the end of 2026. The nitty-gritty details for certification and relying parties are already being worked on. So, if you're doing business in the EU, you'll want to make sure your portals are ready to handle verifiable presentations by 2026-2027. Check out the details here!
Standards are changing quicker than you might expect! W3C Verifiable Credentials 2.0 and Bitstring Status List 1.0 are now officially Recommendations. Plus, OpenID for Verifiable Presentations (OIDC4VP) and Issuance (OIDC4VCI) hit Final Specification status in 2025, and SD‑JWT has achieved RFC 9901. It’s a good time to make sure your IAM and procurement stacks are aligned. (w3.org)
The Identity Provider (IdP) landscape is becoming pretty crowded, and federation is starting to feel a bit unstable. Now, access for contractors and vendors is tangled up in a mix of SAML and OIDC apps, which really complicates things. This makes revocation and auditing for SOC 2 and ISO 27001 a major headache.
Oh, and we can't overlook the headaches that come with helpdesk issues. Password resets are a real time and money drain; even the more cautious estimates in the industry say it can set you back tens of dollars for each reset, not to mention the downtime it creates. According to the Verizon DBIR, stolen credentials are still one of the leading causes of breaches, making up around 22% of incidents. (avatier.com)

The cost of waiting (missed deadlines, failed audits, breach risk)

Missing the EUDI acceptance window could really throw a wrench in your onboarding process with EU customers. Moving forward, wallets and VC proofs are going to be the go-to for KYC and strong customer authentication. If you wait too long to get started, you'll end up rushing to integrate OIDC4VP at the last minute. For all the juicy details, check it out here.
NIST SP 800-63 Rev. 4 dropped in July 2025, and it’s really changed the game for identity proofing, fraud controls, and those ongoing evaluation metrics we’ve all been keeping an eye on. These days, if you want privileged access, you pretty much have to have "phishing-resistant MFA" in your toolkit. If you're not hitting these standards, you can bet it’s going to pop up in your SOC 2 evidence and Zero Trust scorecards. Want to dive deeper? Check it out here.
So, Okta's data for 2025 shows that while phishing-resistant factors are definitely on the rise, they're not getting the attention they deserve just yet. Organizations that are dragging their feet on adopting FastPass/WebAuthn are finding themselves at a greater risk for account takeovers and are having a tough time managing incidents quickly. If you're curious about the details, you can check out the report here.
Credential-based intrusions are still causing a lot of trouble. According to Verizon's 2025 report, about 22% of breaches are happening because of compromised credentials--this is exactly what phishing-resistant measures and VC-gated access are meant to tackle. If you want the complete breakdown, check it out here.

At the end of the day, project delays and audit problems can really pile up, creating some serious risks and bumping up the total cost of ownership in procurement.

7Block’s DID architecture that fits enterprise reality

We’re all about decentralized identity in the areas that matter most--credential issuance, selective disclosure, and revocation. But we don’t stop there; we also ensure that your existing Identity Provider (IdP), device management, and SIEM pipelines stay seamlessly integrated. Our approach emphasizes standards, is compatible with any wallet, and aims to provide you with a great return on your investment.

1) Reference architecture (pragmatic, interoperable)

Identifiers: If you're diving into organizational identities, you should definitely consider did:web. It's a great way to leverage your DNS/TLS ownership and existing PKI. It's also a breeze to set up, super simple to update, and really works well for enterprises. Take a look here.
Credentials: We're working with the W3C VC Data Model 2.0, and it offers two proof profiles designed for different scenarios:
- SD‑JWT (RFC 9901): This is ideal if you're into JWT/AWS/Okta setups. It gives you the ability to do some fine-tuned selective disclosure. If you want to dive deeper, you can check it out here.
- Data Integrity: This profile uses EdDSA/ECDSA with the Bitstring Status List 1.0, ensuring your credentials maintain privacy while lasting a long time. You can find more information about it here.
Protocols: We're using OIDC4VCI for issuing credentials and taking care of their lifecycle, along with OIDC4VP for verification. These are both included in the OpenID Final Specifications from 2025. If you want to dive deeper, check it out here.
Wallets: We're totally on board with Microsoft Entra Verified ID, EUDI wallets, and any other third-party wallets that meet the standards. Microsoft’s platform is now defaulting to did:web and P‑256, which fits right in with NIST crypto baselines. If you want more info, take a look here.
MFA baseline: For our MFA baseline, we're rolling with FIDO2/WebAuthn passkeys and device-bound authenticators specifically for admins and those high-risk applications. We've also teamed up with Okta/Entra to ensure our policies are super resistant to phishing attacks. If you're curious about the details, check it out here.

Where it runs:

IdP: So, you’re sticking with Okta, Entra, or Ping as your go-to identity providers.
Gateways: We’re adding an OIDC4VP verification layer right before those high-risk apps like admin consoles, code repositories, and vendor portals.
Revocation/status: The publisher service handles the Bitstring Status Lists, which come with smart TTL/Cache-Control settings and are delivered via a CDN. You can check it out here: (w3.org).

2) Issuance pipeline (source‑of‑truth to verifiable credentials)

Gather essential info from HRIS, GRC, and training systems.
Issue credentials like “Verified Employee,” “Privileged Admin,” “Vendor of Record,” or “Compliance‑Complete” using OIDC4VCI:
- Map claims to just the necessary data (think “role=approved_admin” and “training=SOX‑2026‑ok”).
- Tie these to the holder key and sign with Ed25519/P‑256, depending on your crypto/geo needs.
- Add credentialStatus pointers to the Bitstring Status List 1.0 for straightforward revocation or suspension on a large scale. (w3.org)
For key management: Host DID Documents under /.well-known for did:web, and store keys in HSM/KMS. Rotate them through CI/CD, while making sure to maintain DNS/TLS continuity. (w3c-ccg.github.io)

3) Verification and access control

Access policy: “Let them in only if they can show the right attribute--without oversharing.”
Flow at the enforcement point:
- First up, the user logs in with phishing-resistant MFA to the Identity Provider (IdP).
- After that, the gateway sends out an OIDC4VP request asking for the right claim (like “privileged_admin=true,” plus freshness and audience binding).
- The holder then presents either an SD-JWT or DI proof; the verifier checks the signature, key binding, and revocation (bitstring check). Once that’s all good, it kicks out a short-lived OIDC token, complete with the embedded authorization context. (openid.net)
Device posture: You might want to ask for device-bound passkey attestation (depending on the IdP's policy) and connect the VC presentation to the same session. This way, you can dodge “MFA fatigue” and avoid any relay issues. (help.okta.com)

4) EU‑readiness and regulated use cases

EUDI wallet acceptance: We’re gearing up to include an OIDC4VP verifier that’s set to support W3C VC 2.0 and ISO 18013‑5 mDL profiles. Basically, this involves registering and certifying relying-party endpoints as per the implementing acts. The aim is to make this acceptance a must by 2026-2027, depending on the industry. For all the nitty-gritty details, take a look here: (consilium.europa.eu).
Microsoft Entra Verified ID: We're excited to introduce Face Check for workforce and supplier credentials! This feature will enhance high-assurance self-service flows, like helpdesk support and passkey activation. The best part? We're doing this without exposing anyone's raw biometrics to apps. Want to know more? Check it out here: (microsoft.com).

5) Where ZK and Solidity actually pay off (no hype)

Zero‑knowledge selective disclosure:
- If you're looking to create unlinkable proofs for different verifiers--like showing that you’ve completed safety training at various plants--definitely check out BBS+ (W3C DI BBS cryptosuites, CR). It’s a great way to keep things discreet and ensure no one can piece things together. (w3.org)
- On the other hand, if you’re into JWT tooling and need something that performs well, plus you want something that developers are already familiar with, SD‑JWT (RFC 9901) is the way to go. It’s got everything you need! (datatracker.ietf.org)
On‑chain minimal anchors (Solidity):
- It's a good idea to keep any personally identifiable information (PII) and credentials off the blockchain.
- If it fits what you're looking for, you can commit rolling Merkle roots of your public trust registries (like issuer allowlists and schema versions) on an L2. This approach lets auditors access tamper-proof evidence and verify things across different organizations without exposing anyone's identity. We achieve this using streamlined Solidity registries that include upgrade-gated governance and emission-aware batching.
Governance proofs:
- Whenever regulators need to make sure that everything’s on the up and up, and there are no data leaks, we turn to ZK proofs. These nifty tools allow us to demonstrate that the right policies were in play during issuance (for example, “KYC-level=2 under policy v17”), while keeping it simple by just showing the policy ID.

6) Observability, compliance artifacts, and procurement fit

Telemetry: We're keeping an eye on verification successes and failures, revocation hits, and the different types of wallets sent to the SIEM, all while being mindful of data minimization.
Evidence packs: Check out our control mappings for SOC 2 CC6/CC7 (that’s all about logical access and change management), ISO 27001 A.5-A.9, plus references for NIST 800‑63‑4 AAL/IAP. And don’t miss the outputs from the OIDC4VP/OIDC4VCI conformance tests. You can get more details here.
EU relying party registration: We’ve crafted some templates for registering your wallet as a relying party (RP) according to the latest implementing acts. For all the nitty-gritty, check it out here.

Two practical examples you can ship this quarter

Admin console “step‑up” with VC and phishing‑resistant MFA

Problem: Admin access is locked down with old-school MFA and group claims in the IdP. This results in a ton of helpdesk-assisted resets whenever incidents pop up.
Pattern:
- Start by getting your admins set up with device-bound passkeys (think Okta FastPass or FIDO2 keys). If your risk assessment points to needing device binding, steer clear of syncable passkeys. (help.okta.com)
- Next, roll out a “Privileged Admin” VC using OIDC4VCI. Don’t forget to add a Bitstring Status List entry so you can quickly suspend access when roles change. (w3.org)
- Secure the admin console with OIDC4VP. Make sure the verifier checks for “privileged_admin=true” along with an audience hash and an expiry time of 90 seconds or less. If everything checks out, generate a temporary admin token that only has the permissions it needs.
- Finally, incorporate Entra Verified ID Face Check into your self-service helpdesk process for recovering passkeys, while ensuring that raw face data stays out of the helpdesk app. (microsoft.com)
What to keep an eye on:
- We’re looking for a 30-60% reduction in admin helpdesk issues, such as resets and proofing.
- Check out the revocation latency in seconds, made possible by the bitstring flip--way better than dealing with those pesky delays from directory syncs. (w3.org)

EU supplier portal: “EUDI‑ready” acceptance

Problem: Your EU procurement portal is set to start accepting national wallets by late 2026. Currently, it’s relying on the old-school username/password combo, plus some static KYC files.
Pattern:
- First off, you’ll want to set up an OIDC4VP verifier that can handle W3C VC 2.0 presentations with status checks. Also, remember to register as a relying party in line with the EU implementing acts. You can get the full scoop on that here.
- Next up, make sure to only ask for what you really need, like “legal_entity_verified=true” along with the VAT ID. It’s a good idea to use SD‑JWT for selective disclosure, paired with Bitstring Status Lists to take care of revocation at the issuer level. You can dive deeper into that here.
- Lastly, try to automate the mapping of verified claims to your procurement roles. This will save you from the hassle of dealing with PDFs.
What to track for outcomes:
- We want to speed up vendor onboarding from weeks to just days--say goodbye to manual document reviews!
- Let’s slice down audit prep time by using cryptographic proofs and status logs instead of relying on those old screenshots.

Emerging best practices we implement by default

Choose your proof format based on the system boundary:
- If you're working with app gateways and JWT ecosystems, you’ll want to go with SD‑JWT (RFC 9901). But if you need unlinkability across different ecosystems, DI + BBS+ is the way to go. You can dive into the details at (datatracker.ietf.org).
If you're in the enterprise world, did:web is definitely the way to roll. It keeps your ledger-anchored DIDs secure for those ecosystems that really need global, censorship-resistant identifiers. Oh, and by the way, Microsoft’s Verified ID has made the switch to did:web and is now using NIST-compliant P-256 as the default. You can check out more details here: (w3c-ccg.github.io).
Consider wallets as security checkpoints: pair OIDC4VP with phishing-resistant MFA and always check the device's health. Also, don’t forget to implement an admin step-up using passkeys. For more details on this, check out (help.okta.com).
If you're looking to revoke at scale, consider rolling out Bitstring Status List 1.0. Just remember to set your TTLs and cache controls to keep verifier correlation in check and avoid those pesky stale checks. For all the details, check it out at (w3.org).
Get a head start on testing for conformance: go ahead and run OpenID's conformance tests for OIDC4VCI/OIDC4VP, and don’t forget to include those reports in your SOC 2 evidence. If you want to explore this in more detail, check it out at (openid.net).

What changes for ROI, not just architecture

Fewer credential-related incidents: Verizon reports that around 22% of breaches are tied to compromised credentials. However, if you switch to phishing-resistant multi-factor authentication (MFA) and verified credentials (VC), you can significantly reduce those risks. For more info, take a look here.
Cut down on helpdesk costs and downtime: By moving to device-bound passkeys and letting users verify themselves, you can really reduce those pesky password reset requests. Some industry estimates show that each manual password reset could set you back a good chunk of change--possibly even tens of dollars. Plus, consider the downtime that comes with it! If you're curious about the costs, check it out here.
Faster vendor onboarding and audits: Swapping out those endless email chains and screenshots for cryptographic proofs really speeds things up. And thanks to eIDAS 2.0, you won’t have to navigate a maze of different rules across the EU. If you're curious about this framework, check it out here.

How 7Block delivers in 90 days

Week 0-2: Let’s start by exploring the identity landscape and get a handle on compliance mapping for SOC 2, ISO 27001, and NIST 800-63-4. We’ll also sketch out a risk model and choose our target app.
Week 2-6: Now it's time to set up our issuance pipeline using OIDC4VCI. We’re going to establish the did:web registrar, get the Bitstring Status List service up and running, and tweak some IdP policies to ensure we have that phishing-resistant MFA in place.
Week 6-10: We’ll connect the OIDC4VP verifier for one admin console and one supplier portal. On top of that, we’ll add in some SIEM/monitoring hooks and run a few conformance tests (OIDC4VCI/OIDC4VP). For more details, check out openid.net.
Week 10-12: We’ll get ready for EU RP registration if it's necessary, update our runbooks, and refresh the SOC 2 evidence pack.

Where We Plug In:

Looking to get some build-outs done? Check out our fantastic web3 development services and blockchain development services we’ve got in store for you.
Need to bolster your security? We’ve got you covered with our exceptional security audit services.
Want to link up your IdP, wallets, and apps? Our expertise in blockchain integration is just what you need.
Thinking about creating a verifier or trust registry on an L2? Don’t worry--we’re here to help with our efficient smart contract development services.

In‑depth technical notes

Here’s what’s new with Microsoft Entra Verified ID:
- It now automatically defaults to did:web since ION is being phased out in the admin UI. It also supports P‑256 for better alignment with NIST standards. And don’t forget about Face Check--it offers reliable, high-assurance verification while ensuring your biometrics stay safe from apps. (learn.microsoft.com)
Here’s the lowdown on Okta's policy controls for phishing-resistant MFA:
- If you’re an admin, you’ve gotta make FastPass or FIDO2 mandatory. And if your AAL3 policy includes device binding, make sure to block those syncable passkeys. Also, remember to use RP-ID scoping for subdomain families to really tighten up your security. Check out more details here.
Standards maturity update:
- Exciting news! VC 2.0 and the Bitstring Status List are now officially W3C Recommendations. Meanwhile, OIDC4VCI and OIDC4VP have also hit the milestone of OpenID Final status. On the other hand, SD‑JWT is sitting at RFC 9901, and BBS+ is still a W3C Candidate Recommendation, but it's showing great progress in terms of interoperability. So, when you're planning your deployments, keep these updates in mind! (w3.org)

If you’re in the market for a team that provides identity solutions that are “boringly secure”--you know, the type everyone from your auditors to CISOs and developers can back--let’s connect!

Book a 90-Day Pilot Strategy Call

Ready to dive in? Let’s have a conversation about what you want to achieve and how we can map out a plan to hit those goals in just 90 days. You can easily grab your strategy call right here!