Credential Fraud, Credential Mills and Security Threats

Threat modelling and controls for credential systems.

Course ID: ICB-A08. This course sits at level L4 "Assure" of skill SECP "Security, privacy and data protection" in the ICoBC Credentialing Skills Framework (ICSF). It belongs to the VRITE pillar Trustworthiness and is delivered at stage A "Ability": you practise a capability on realistic tasks in a controlled setting.

At this level the skill is: leads threat modelling and fraud prevention for credential systems; advises on key management and long-term validity.

Who it is for

• HR and learning technology owners
• Quality, registry and admissions staff
• Education IT and credential operations
• Professional bodies and sector associations
• ICoBC Lead Reviewers

Prerequisite: ICB-P07 Open Badges 3.0 and Verifiable Credentials: Hands-on Lab. You should be able to describe how an issuer signs a credential and how a verifier checks it.

Learning outcomes

After this course you can:

1. Model threats to a credential system: forgery, impersonation, key compromise, credential mills and misuse.
2. Select controls including key management, status lists and issuer registries.
3. Plan incident response, including mass revocation.
4. Assess the long-term validity of signed credentials.

Workload. The course is a workshop with 8 hours of notional learning. This file covers the self-paced part. Live or workshop elements appear as facilitator notes in each module.

How it is assessed. You produce a threat model and a control plan for one credential system. A person assesses your work with the rubric in the section "Assessment and badge". A short knowledge check supports the task. Nothing in this file grades your work automatically.

Badge. "Credential Fraud, Credential Mills and Security Threats (Ability, L4)", alignment code ICSF-SECP-L4-A. Evidence: threat model; control plan.

Completing this course and earning the badge shows that you have practised these tasks in a controlled setting. It does not prove competency in any job.

The threat landscape

Why credentials attract attackers

A credential is a claim that other people rely on. Employers use it to hire, registrars use it to admit, regulators use it to license. Where a claim carries value, someone will try to fake it, steal it or misuse it. Security work on credentials starts from this simple fact.

This module gives you a vocabulary for the main threat families. You will use it in Module 2 to build a model.

Four assets matter in most credential systems:

• The credential itself: the signed data that states what was achieved.
• The signing key: the secret that makes a credential genuine.
• The earner's identity link: the connection between a credential and the person it describes.
• Trust in the issuer: the belief of verifiers that this issuer is real and careful.

An attack on any of these damages the whole system. A forged credential harms the verifier. A stolen key harms every earner of that issuer. A fake issuer harms the reputation of all genuine ones.

Forgery and alteration

Forgery means creating a credential that looks genuine but was never issued. Alteration means changing a genuine credential, for example raising a grade or extending a date.

Paper and PDF certificates are easy to forge because verification depends on a human looking at the page. Digitally signed credentials make forgery harder, because a verifier checks a signature instead of a layout. Forgery then needs one of three things: a stolen key, a weak verifier that skips the signature check, or a trick that makes the verifier trust a fake issuer.

A weak verifier is a common gap. A verification page that shows a green tick based on the credential's own claims, without checking the signature or the issuer, gives no security at all.

Impersonation

Impersonation means presenting a genuine credential that belongs to someone else. The credential is real, but the person showing it is not the earner. Two forms occur often:

• Credential sharing or selling: an earner passes a credential or login to another person.
• Account takeover: an attacker gains access to an earner's wallet or badge account.

Controls here bind the credential to the holder, for example through holder-proof during presentation, and protect the accounts that store credentials.

Key compromise

The signing key is the most valuable single asset. If an attacker obtains it, the attacker can issue credentials that pass every technical check. Keys leak through poor storage, shared accounts, departing staff, malware and misconfigured cloud services. You will study key management in Module 3 and the response to a compromise in Module 4.

Credential mills

A credential mill, sometimes called a diploma mill or accreditation mill, sells credentials with little or no assessment of learning. Some mills simply sell certificates. Others create the appearance of legitimacy with a professional website, an invented accreditor or a cloned copy of a real institution's name.

Digital credentials make mills a different problem. A mill can issue technically valid, correctly signed credentials. The signature proves who issued the credential. It does not prove that the issuer is a real and reputable body. The defence is a way for verifiers to check the issuer against a trusted list, which is the role of an issuer registry.

Misuse

Misuse covers genuine credentials used in ways the issuer never intended. Examples include a badge for attending a webinar presented as proof of professional competence, an expired credential shown as current, or a credential scraped from a public page and used in a profile. Misuse is often a gap in design: unclear claims, missing expiry, or missing status information.

AI-generated fake credentials and misuse by agents

Generative AI lowers the cost of producing convincing fake documents: certificates, transcripts, verification web pages and supporting emails. A fake certificate can now match a real institution's layout closely. This weakens any check based on appearance.

Software agents add a second concern. An agent that acts for a user may handle credentials: collecting them, presenting them, or verifying them for an employer. Risks include an agent presenting credentials without the earner's informed consent, an agent over-sharing personal data, and an agent that trusts a fake verification page. Treat agents as actors in your threat model, with defined permissions.

Where a check relies on how a document looks, assume AI can imitate it. Where a check relies on a signature and a registry lookup, the attacker needs more than a good image.

Worked example: Two organisations, one threat family

University context. The registry office of a university (illustrative) receives an application with a certificate from a partner college. The PDF looks perfect. An admissions officer pastes the college name into a search engine and finds a polished website with an accreditor that lists the college. The accreditor's own site was registered three weeks ago. The signature and issuer checks in the registry's tool would have flagged this at once, because the college's key is not in the sector's issuer registry. Lesson: appearance and web presence can both be faked; a registry check cannot be faked by design work alone.

Corporate context. A talent acquisition specialist at a corporate group (illustrative) screens candidates who list a "leadership certification" from a provider she does not know. The candidate sends a link to a verification page. The page is hosted by the provider and always says "valid", whatever ID is typed in. Lesson: a verification service run by the same party that may be a mill proves nothing. The specialist needs an independent trust anchor.

Practice activity: Classify ten incidents

Read the ten short incident descriptions below. For each, name the main threat family (forgery, impersonation, key compromise, credential mill or misuse) and the asset that is attacked first.

1. A former trainer still has access to the signing account after leaving, and issues badges to friends.
2. A website sells "executive diplomas" within 24 hours, with no coursework.
3. An employee's badge wallet password is reused from a breached site, and an attacker presents the employee's credentials.
4. A graduate edits the grade in the PDF export of a transcript.
5. A learner gives a classmate a screenshot of a certificate to use in a job application.
6. A company shows "Certified safety professional" next to a badge that only records attendance at a one-hour talk.
7. A verification page accepts any file and shows a green tick.
8. An AI tool generates a transcript on a real college's letterhead.
9. A software agent presents a learner's full credential set to a recruiter site without asking.
10. A signing key is stored in a shared folder with open read access.

Write your answers in two columns. Keep them: you will reuse the list as seed material for Module 2.

Check your understanding

Threat modelling

What a threat model is

A threat model is a structured description of what you protect, who might attack it, how, and what you will do about it. It is a working document. It does not need to be long, but it needs to be specific to one system.

Use four questions:

1. What are we building and protecting?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

This module gives you a repeatable method for the first two questions. Module 3 covers the third. The fourth is your review step.

Step 1: Draw the system

Start with a simple data flow diagram. Show the actors, the components, the data that moves between them and the trust boundaries, which are the places where data crosses from one party to another. A credential system usually has these elements:

• an issuer system with a signing service and a key store
• a learner records source, such as a student information system or learning platform
• an earner wallet or badge account
• a verifier such as an employer or registry
• a status service that tells verifiers whether a credential is still valid
• an issuer registry or trust list
• optionally, software agents acting for a user or verifier

Draw the arrows for issuing, holding, presenting and verifying. Mark each trust boundary.

Step 2: Identify threats

For each element and each arrow in your diagram, ask what could go wrong. A useful prompt list is the STRIDE set: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. You do not have to use every prompt for every element. Use them as a checklist to avoid blind spots.

Map the threat families from Module 1 to the diagram:

• Forgery and alteration: tampering with learner records before signing, or with a credential in transit.
• Impersonation: spoofing the earner at the wallet or in a presentation.
• Key compromise: information disclosure at the key store; elevation of privilege on the signing service.
• Credential mills: spoofing the issuer, where a fake issuer is accepted by a verifier.
• Misuse: unintended use of correct data, including by agents.

Add threats that are specific to your system. A system with a public verification API has a denial of service threat. A system that issues from a bulk upload has an injection and mistake threat: one bad file can produce thousands of wrong credentials.

Step 3: Rate and rank

You cannot fix everything first. Rank threats by likelihood and impact. Keep the scale simple: low, medium, high. Write the reason for each rating in one sentence. A rating without a reason cannot be reviewed.

Impact deserves care. Ask who is harmed and how:

• the earner (loss of opportunity, privacy harm)
• the verifier (a bad hire or admission)
• the issuer (reputation, legal exposure)
• the wider ecosystem (loss of trust in the credential type)

A compromised signing key usually scores high on impact because it affects all earners at once. A single shared screenshot may score low.

Step 4: Record the model

A usable threat model is a table. Keep it short enough that someone will read it, and keep an owner and a review date.

Include assumptions and out-of-scope items. State, for instance, that the learner records source is trusted for this exercise but will be reviewed separately.

Agents in the model

If software agents act for earners or verifiers in your system, add them as actors. Ask four questions: What may the agent do? On whose authority? What data can it see? How does a human stop it? An agent that can present credentials needs a limit on which credentials and which verifiers, and a log of what it presented.

Worked example: Threat model for a college badge programme

Training provider context. A vocational college (illustrative) issues skills badges to 4,000 learners a year. Its learning platform sends completion data to an issuing service. A cloud-hosted key signs the badges. Employers verify through a public page.

The college's digital learning lead draws the diagram and lists these threats:

She ranks T2 and T5 first, because impact is high and the cause is cheap to remove.

Corporate academy context. A corporate academy (illustrative) issues internal compliance badges. The model looks different: there is little credential mill risk, but internal misuse is high. Managers present expired compliance badges as current. The academy's L&D manager rates T4 (stale presentation) high and adds an expiry and status check to the list of controls to select.

Practice activity: Build a one-page threat model

Choose a system. Use the case in your own organisation if you can. If not, use the college or academy case above.

1. Draw the data flow diagram with at least five elements and two trust boundaries. Hand-drawn is fine.
2. List at least eight threats, covering all five threat families from Module 1.
3. Rate each threat for likelihood and impact, with a one-sentence reason.
4. Mark the top three threats and note who owns each.
5. List two assumptions and two out-of-scope items.
6. Add at least one agent-related threat or state why no agent is present.

Save the result. It is the first draft of your assessed threat model.

Check your understanding

Controls

From threats to controls

A control is something you do or build to reduce a threat. Good control selection links each high-ranked threat to one or more controls, states who owns the control, and notes how you will know it works.

Use three types of control together:

• Preventive: stops the attack, for example protecting a key in dedicated hardware.
• Detective: notices the attack, for example logging every signing operation.
• Corrective: limits the damage, for example revoking affected credentials.

No single control is enough. A system that relies on prevention alone has no plan when prevention fails.

Key management

Because key compromise has high impact, key management deserves most of your attention. Cover these areas in your plan:

• Generation: create keys in a controlled environment, using approved algorithms.
• Storage: keep private keys in a hardware security module or an equivalent protected service, not in code, shared folders or email.
• Access: limit who and what can request a signature. Separate duties: the person who approves an issuing batch should not be the only person who holds signing authority.
• Use: log every signing operation, with the batch, the requester and the time.
• Rotation: change keys on a schedule and after any suspected exposure.
• Backup and recovery: plan how to continue if a key is lost.
• Retirement: keep public keys available after retirement so old credentials stay verifiable, and record the dates a key was valid.
• Offboarding: remove access when staff leave or change roles.

Write a key policy that is short enough to be followed. Name an owner.

Status lists

A status list lets an issuer tell verifiers whether a credential is still valid, suspended or revoked, without contacting each holder. In the W3C Verifiable Credentials ecosystem, status lists are published as a compact list in which each credential has a position. A verifier fetches the list and checks the position for the credential in front of it.

Three design points matter:

• Privacy: a status list should not reveal which individual credential a verifier is checking, nor let observers learn who holds which credential. Compact lists shared across many credentials help with this.
• Availability: if the status service is down, verifiers must know what to do. Decide whether a failed check means "unknown" or "reject", and say so in guidance for verifiers.
• Freshness: set how often the list is updated and how long verifiers may cache it.

Specifications for status lists continue to evolve. Check the current versions before you commit to a design.

Issuer registries

An issuer registry, also called a trust list, is a record of issuers that a community accepts. A verifier looks up the issuer's identifier and public key in the registry. If the issuer is not listed, the verifier treats the credential with caution or rejects it.

A registry answers the credential mill problem. The signature shows who signed. The registry shows whether that signer is recognised by the community the verifier trusts.

Questions to settle when you design or join a registry:

• Who governs it, and by what criteria is an issuer admitted?
• How is an issuer removed, and how fast?
• How are keys linked to the issuer entry, and how are key changes recorded?
• Who may query it, and is the query itself a privacy risk?
• What does a verifier do if the registry is unreachable?

A registry is only as strong as its admission rules. A registry that admits anyone who pays a fee protects nothing.

Other controls worth selecting

• Holder binding: link a credential to the earner so a presenter must prove control of a holder key or identifier.
• Identity proofing at issue: check identity at the level the credential's value justifies.
• Verifier hardening: verify signatures, check status, check the registry and do not show a result based on unsigned claims.
• Rate limits and monitoring: detect unusual issuing volumes, such as 2,000 credentials in ten minutes from an account that normally issues 20 a day.
• Two-person approval for bulk issuing.
• Clear claims, criteria and expiry in the credential, which reduce misuse.
• Agent permissions: scoped authority, consent steps for sharing and an activity log.
• User education: help verifiers recognise that a polished page or PDF proves nothing.

Selecting controls with a matrix

Link every top threat to at least one preventive, one detective and one corrective control. Then check for cost, effort and side effects. A control that blocks real learners from using their credentials has a cost too.

Worked example: A control plan for key theft

University context. Take threat T2 from a university's threat model: the signing key for degree credentials could be copied from the deployment environment. The registrar and the head of IT (illustrative roles) agree these controls:

Corporate context. A corporate academy applies a lighter version for internal compliance badges. It keeps the protected key store and the signing log, drops two-person approval for small batches and keeps it for batches above 200 credentials (illustrative). The HR systems lead records that this was a deliberate choice and sets a review date.

Practice activity: Select controls for your top threats

Take the top three threats from your threat model of Module 2.

1. For each, select at least one preventive, one detective and one corrective control.
2. For the credential mill threat, write how a verifier uses an issuer registry, and what happens when the issuer is not listed.
3. Write a half-page key policy covering generation, storage, access, rotation, backup, retirement and offboarding.
4. Write the verifier guidance for a failed status check: unknown or reject, and why.
5. Name an owner and a piece of evidence for each control.

Keep your work for the control plan.

Check your understanding

Incident response

Why plan before an incident

When a signing key leaks or a fake batch appears, there is little time. Decisions about who may revoke, how to tell verifiers and what to say to earners are hard to make under pressure. A plan prepared in advance, and tested, turns a crisis into a procedure.

An incident response plan for a credential system covers six phases:

1. Prepare: roles, contacts, tools, logs, drills.
2. Detect and report: how an incident is noticed and who is told.
3. Assess: what happened, how many credentials and people are affected, whether it is still going on.
4. Contain: stop further harm, for example by disabling a signing account.
5. Recover: restore trustworthy operation, for example with a new key and re-issued credentials.
6. Review: learn and improve.

Roles and decisions

Name roles, not just people, and name deputies. A typical set:

• Incident lead: coordinates and decides.
• Technical lead: handles keys, systems and logs.
• Registry or academic lead: confirms which credentials are genuine.
• Communications lead: informs earners, verifiers and the public.
• Legal and data protection contact: advises on duties to notify.
• Registry or ecosystem contact: informs the issuer registry or trust list operator.

Decide in advance who may order mass revocation. If only one person can, and that person is on leave, the plan fails.

Mass revocation

Mass revocation means withdrawing many credentials at once. It follows a key compromise or a bulk issuing error. Plan for it in four parts:

1. Scope. Define which credentials are affected. If a key was exposed from a known date, all credentials signed with that key after the earliest possible exposure are suspect. If the date is not known, the whole set signed with the key may be suspect. Your signing log is the source of truth. Without a log, scope is guesswork.

2. Mechanism. Use the status list to mark credentials as revoked or suspended. Suspension gives time to verify which credentials are genuine and then restore them. Retiring the key in the registry tells verifiers that signatures made after the compromise date should not be trusted.

3. Recovery. Generate a new key under proper controls. Re-issue credentials to genuine earners from trusted records. Genuine earners should not carry the burden of the incident: make re-issue automatic or simple.

4. Communication. Tell affected earners what happened, what they must do (often nothing) and where to get help. Tell verifiers which credentials to treat as invalid. Do not wait for every fact before sending a first message; say what you know and when you will update.

Think about earner harm. A revoked credential may be used in a live job application. Offer a verification letter or a quick re-issue channel, and keep a contact for verifiers.

Credential mills and fake issuers

Incidents also come from outside. A fake issuer copies your name or a fake credential carries your logo. Plan for takedown and reporting: contact the hosting provider, the domain registrar and the relevant trust list. Keep evidence: screenshots with dates, URLs, headers. Publish a clear statement of how verifiers can confirm genuine credentials from your institution.

Incident timeline

Review and learning

After the incident, hold a review within a few weeks. Ask what the plan assumed that proved false, which controls worked, and which missed. Update the threat model and control plan. Share what you can with the community: other issuers face the same threats.

Worked example: Mass revocation after a key exposure

Training provider context. A training provider (illustrative) finds that its signing key sat in a code repository that was public for nine days. Its signing log shows 1,850 credentials signed in that period and 14 signed from an unknown address. The incident lead decides: disable the key, suspend all 1,850 credentials through the status list, and verify the 14 against course records. Within 48 hours the registrar confirms 1,836 genuine credentials and 14 fake ones. A new key is created, the 1,836 are re-issued without any action by the earners, and the 14 are revoked. The communications lead sends a plain-language message to earners and to registered employers, with a contact address.

Corporate context. A corporate academy (illustrative) discovers that a departed contractor's account was used to issue 120 "senior reviewer" badges to staff in one department. The HR systems lead suspends the 120 badges, confirms with line managers which were earned, restores 85 and revokes 35. The academy removes the contractor's access, adds an offboarding check for all signing accounts and informs the department head. The review notes that no alert fired, because the volume was below the threshold. The threshold is lowered.

Practice activity: Draft an incident response plan with a mass revocation procedure

1. Write the six phases for your chosen system, with named roles and deputies.
2. Write a one-page mass revocation procedure: scope, mechanism, recovery and communication.
3. Draft two messages: one to affected earners and one to verifiers. Keep each under 150 words, in plain language.
4. Define two measurable targets, for example time to disable a key and time to publish revocation. Mark them as your own targets.
5. Plan a drill: scenario, participants, what you will measure.

Check your understanding

Long-term validity

What "valid" means over time

A credential may need to be checked years after it was issued. A degree may be verified at the point of a job application, but also during a promotion decades later. A professional licence credential may be checked every year. Validity over time is a design question, not an accident.

Consider two ideas:

• Validity at the time of issue: was the signature genuine and the key trusted on the day the credential was signed?
• Validity now: does the credential still verify today, given changes in keys, algorithms, registries and status?

A credential can be genuine at issue and fail today if the issuer's key has been retired without publishing it, the issuer has closed, the verification service has gone offline or the signing algorithm is no longer considered safe.

Threats to long-term validity

Plan for these:

• Key loss or retirement: the public key is no longer available.
• Issuer closure or merger: nobody runs the status service or registry entry.
• Algorithm ageing: cryptographic methods weaken over time as attacks improve.
• Format and specification change: the data model or securing mechanism evolves and verifiers drop support.
• Resolution failure: identifiers cannot be resolved because a web domain lapsed or a service ended.
• Registry change: the issuer is removed or renamed.

Keeping credentials verifiable

Controls that help:

• Publish and preserve public keys with their validity periods, in more than one place where possible.
• Record issuance time in a way verifiers can trust, so a verifier can ask "was this key valid when the credential was signed?" and not only "is the key valid now?".
• Plan issuer succession: name who maintains status and key records if the issuer closes. For education, this may be a successor institution, a national body or an archive. For professional bodies, it may be a sister association.
• Use stable identifiers and keep the domain and hosting under long-term control.
• Set status list retention rules: keep lists available long after expiry.
• Offer re-issue or re-signing when algorithms or formats change, with a clear process for earners.
• Keep a verifiable archive of the credential's evidence if the claim needs it, within data protection limits.
• Set sensible expiry: not every credential should be valid forever. A first aid badge may expire after a fixed period. A degree usually does not.

Cryptographic ageing and post-quantum migration

Cryptographic algorithms are chosen for a lifetime of expected safety. If a credential needs to stay verifiable for decades, you must consider that the algorithm used today may weaken within that time.

Post-quantum cryptography is a Watch topic. Standards bodies have published standards for some post-quantum algorithms. Migration of credential ecosystems to such algorithms is not yet planned at scale.

What an L4 practitioner can do now, without claiming more than is known:

• Record which signing algorithms and securing mechanisms each credential uses.
• Keep an inventory of keys, algorithms and where they are used.
• Design for crypto agility: be able to change algorithms without redesigning the whole system.
• Ask suppliers and standards groups about their migration plans.
• Decide how long each credential type needs to stay verifiable, and weigh that against algorithm risk.
• Monitor guidance from standards bodies and national security agencies.

Do not promise customers that credentials are "quantum-safe". State what you know and what you monitor.

The data model and securing mechanisms

The W3C Verifiable Credentials Data Model 2.0 is an Established topic: it is a W3C Recommendation, published in 2025. Related specifications for status lists and securing mechanisms continue to evolve. For long-term planning, this means the core data model is stable enough to build on, while some surrounding choices need periodic review. Add a review date to your design for each dependency, and note which parts are Recommendation-level and which are still developing.

Assessing long-term validity

When you assess a system's long-term validity, ask these questions:

1. How long must each credential type remain verifiable?
2. Which keys, algorithms, identifiers and services does verification depend on?
3. What is the weakest dependency, and what happens if it fails?
4. Who is responsible if the issuer closes?
5. How will you change algorithms or formats, and what will earners have to do?
6. When will you next review the answers?

A good answer names owners, dates and fallbacks.

Worked example: A validity assessment for degree and compliance credentials

University context. A university registrar (illustrative) must keep degree credentials verifiable for the lifetime of the graduate. She lists dependencies: a signing key under the university's control, a domain, a status list and an entry in a national registry. She finds three weaknesses. The key's public part is only on the university's website. The status list is deleted after the credential's nominal expiry, which is blank for degrees. No successor is named if the university merges. Her recommendations: publish key history in the national registry and an archive, keep status lists indefinitely for non-expiring credentials, and sign a succession agreement with a named partner.

Corporate context. A corporate academy (illustrative) issues compliance badges that expire after 24 months and a leadership programme badge with no expiry. The HR systems lead decides that compliance badges need verification for only five years after expiry, for audit. The leadership badge needs verification for as long as the employee's records are kept. She adds an algorithm inventory and sets an annual review, including checks of guidance on post-quantum migration. She notes that the academy's brand domain is managed by a marketing team and moves it into the IT asset register, with auto-renewal and two named contacts.

Practice activity: Assess long-term validity for your system

1. For each credential type in your system, state how long it must stay verifiable and why.
2. List every key, algorithm, identifier, service and registry that verification depends on.
3. For each dependency, state the failure, the effect and the fallback.
4. Write a succession statement: who maintains keys, status and registry entries if the issuer closes.
5. Write a short algorithm and format migration plan, including who tells earners and how.
6. Set review dates and note which dependencies are Recommendation-level standards and which are still evolving.

This becomes the long-term validity section of your control plan.

Check your understanding

Assessment and badge

The task

Assessed task: Threat model and control plan for one system

Choose one credential system. It can be a real system in your organisation, a system of a client or a realistic system from the worked examples. If you use a real system, remove confidential details and personal data before submission.

Submit two documents.

1. Threat model (about 3 to 5 pages)

• System description and scope.
• Data flow diagram with trust boundaries.
• Threat table with at least 12 threats covering forgery, impersonation, key compromise, credential mills and misuse, and at least one threat involving AI-generated fake credentials or software agents.
• Ratings with reasons, owners, assumptions and out-of-scope items.

2. Control plan (about 4 to 6 pages)

• Controls for the top five threats, with preventive, detective and corrective types, owners and evidence.
• Key management policy summary.
• Status list design decisions, including behaviour on failed checks.
• Issuer registry approach, including how verifiers treat unlisted issuers.
• Incident response plan with a mass revocation procedure and two draft messages.
• Long-term validity assessment, including succession and an algorithm and format migration approach.
• Review dates and a list of dependencies marked by maturity.

Allow about 2 to 3 hours for the task after the workshop sessions. Work alone or in a pair for the live exercises, but submit your own work.

Rubric

A trained assessor rates each criterion on a four-level scale. The assessor gives written feedback for each criterion.

Pass rule

To earn the badge you must:

1. Score at least 3 (Secure) on the criteria "Threat coverage", "Control selection" and "Incident response and mass revocation".
2. Score at least 2 (Developing) on all other criteria.
3. Pass the final knowledge check below with at least 8 of 10 questions correct.

An assessor may ask for a revision if one or two criteria fall short. A revised submission is assessed against the same rubric.

Evidence submitted for the badge

• Threat model (document, with diagram).
• Control plan (document, including incident response and long-term validity sections).
• Assessor's written feedback and rating for each criterion.
• Record of the final knowledge check result.

The badge is "Credential Fraud, Credential Mills and Security Threats (Ability, L4)" with alignment code ICSF-SECP-L4-A. It records that you completed practice tasks to the stated standard in a controlled setting. It does not prove competency in any job.

Final knowledge check

Answer all ten questions. Each question has one correct answer.

Sources and further reading

Status: November 2026.

• W3C, Verifiable Credentials Data Model v2.0, W3C Recommendation. Published by the World Wide Web Consortium at www.w3.org.
• W3C Verifiable Credentials Working Group, specifications for status lists and for securing mechanisms. These are related specifications that continue to evolve. Check the working group page at www.w3.org for current versions and maturity levels.
• 1EdTech Consortium, Open Badges Specification, version 3.0. Published at www.1edtech.org.
• National Institute of Standards and Technology (NIST), post-quantum cryptography project and published standards. See www.nist.gov.
• NIST, Computer Security Incident Handling Guide, Special Publication 800-61. See www.nist.gov.
• NIST, Recommendation for Key Management, Special Publication 800-57. See www.nist.gov.
• OWASP Foundation, Threat Modeling resources. See owasp.org.
• ICoBC, Credentialing Skills Framework (ICSF), skill SECP and the VRITE pillars. Available from the International Council on Badges and Credentials, info@icobc.net.

Time-sensitive statements in this course: the status of the W3C Verifiable Credentials Data Model 2.0 as a Recommendation since 2025; the state of status list and securing mechanism specifications; the state of post-quantum standards and credential ecosystem migration. Status: November 2026.