**Full Disclosure — I have been working in both software and system development for over 25 years and have been lucky to bring solutions to both enterprise and carrier markets. I am currently the CTO of EdTech company that builds solutions using a secure-by-design approach. My background includes research where I was awarded 5 patent grants for technology in carrier networks. This includes over 20 years of ISO/IEC standards experience as an expert , editor, and HoD for Canada. **

I have been working on this project for more years than I care to remember and want to share my insiders view of this project and some real dangers this standard poses to innocent buyers of the vendors who “claim” conformance to this standard. Given that there is a full project review underway the time is right for making this standard for the masses. This includes helping vendors to find affordable methods for developing and maintaining secure software.

The Bases for this Standard

This project started from the Ph. D of the lead editor. At the time of writing, 2008, the security landscape was very different than it is now and applications meant different things in different sectors of the development and engineering sectors including the technologies used to develop them. With a lead editor that only sees this through the lens of his Ph D and not the industry need, it is very difficult to develop something that is not complex and that can provide a means for any organization to develop secure software. If you know ISO rules, you will quickly realize that this clashes completely with ISO rules for consensus based approach.

BTW, the editor has a great “intro” course he will provide any willing participant who wants to spend 3 hours of their life and 400 Powerpoint slides to educate you to the base concepts of this standard. I am not kidding you when I say many ISO delegates need to drink during these sessions. Keep in mind, this slide deck is 400 slides with lots of detail. You need to understand these concepts to implement this standard. Which gives you a little sense to level of complexity and serious skills need to do this work.

The Standard

As this project was focused on securing web applications and that was the premise of the Ph. D these concepts got embedded into the standard.

I will not breakdown each part of standard in detail but only provide that there is Overview and Concepts and many supporting documents. In total there are 8 parts which will set you back about 1200 Euros ($1750 CDN) to buy the entire collection. It details a framework for securing applications however development details are not provided. This part is 80 pages which gives you a sense to the level of complexity. Several parts are just XML so don’t purchase those unless you really need them. If you have bought those in error, I apologize for this. Basically, the following are some key aspects that are not considered.

ISO/IEC 27034 is not intended to be used for the following:
– Development standard for software applications
– Application project management standard or similar
– A Software Development Lifecycle (SDLC) standard

ISO/IEC 27034 does not provide any guidance on the following:
– Guidelines for technologies such as cloud, AI, physical, or network security
– Controls for measurement (metrics) nor considerations
– Secure coding strategies for any programming language
– Mandatory requirements in any form

I highlight these due to fact that industry has adopted this series was explicitly for the reasons above. This includes that many multi-national corporations hold “certifications” for it! Did I mention that there are no requirements in this standard as it is a framework only. It is anyone’s guess what they are claiming or what specific requirements they actually meet. SAP provides lots of documentation on their implementation of their SDLC using this standard. However, with no requirements and the fact that it does not cover an SDLC makes one a little puzzled to what exactly are they claiming to do. If someone can figure this out please share, I would love to know.

The base concept of an Application Security Control (ASC) is defined as a control to mitigate the risk. This can in essence be anything the only requirement is the format. The vendor unilaterally gets to decide this control including how it is measured. For example, they can create a ASC that states that failed logins are allowed with no further action or mitigation. This is a valid ASC and the buyer would be tasked with understanding what this means for a risk scenario.

The author will tell you that these are driven by the buyer but how many companies buying software will write these for the software they purchase when they don’t even know the technology or have the necessary capabilities of cyber for software development? Again, as stated above the vendor generates these with no requirements or minimums.

Other concepts build on how you then take these and put them into a governance model however this does not currently align to ISO/IEC 27002 which has defined requirements for software development. The editor will argue it does even as Part one is over 12 years old and 27002 was just published last year.

The Challenge and Risks

As you can tell this blog is born out of frustration with this project and how we have created a model of security by obscurity. A standard that pertains to do one thing but does not really move the needle on developing secure code or software. With the need to show that you’re secure, ISO has become a go to for organizations who want to demonstrate a gold standard and this is where the risk of exposure exists.

For any company that is looking to use a vendor that makes these claims you need to do your homework and determine what have they really implemented and does it align to other standards such as ISO/IEC/IEEE 12207:2017 Systems and software engineering Software life cycle processes for secure software development. You may also want to reference and research the following standards:

Governments movement to Secure-by-Design
European Union Cyber Resilience Act (CRA)
NIST Secure Software Development Framework

This is but a small sample to provide detailed guidance on creating secure software driven by industry and regulators. Software can be secure but it takes structure and due diligence on the part of the vendor. This needs a governance infrastructure which requires process, procedure, and a risk management framework. It is not a “one and done” but embedded and part of a companies culture.

Implementation will be very sector specific as many sectors might have a regulatory requirements they must meet. If you are unaware of market requirements get to know them fast, and as always in the software world it is a case of buyer beware. Standards such as ISO 27001 and NIST Cyber Framework provide lots of details on how to implement such a framework.

If you are looking to buy software from a vendor who claims implementation or a certification to ISO 27034, you must require the full disclosure of the ASCs including the testing results. If they claim this is not an easy task or if they don’t provide them you would have grounds to question what they are really doing and do they really have secure software.

Based on the current state of cyber insecurity, we know that current vulnerabilities and compromises can be fully traced back to the approaches used and considered at development time. There are ways to secure software but many organizations are just not equipped to implement them from either a governance or skill set perspective. For example, ISO 27002 has a requirement for ensuring staff skills but this concept does not exist in 27034 nor is any guidance for implementing a ASC for this control provided. We also know based on the quickly changing landscape for technology this is a moving target so keeping your developers and engineers current to cyber risks is critical. And no, using a cloud provider is not going to fix this as they are dealing with these same issues of resources and talent. You cannot transfer risk, you must be willing to accept it or mitigate it.

The most risk here is this model is being proposed for other projects in both the ISO/IEC. The problem is that the approach has not changed only the names to append new concepts such as “IoT”, “Cloud”, and “AI”. It does not consider any specifics of these technologies the editor again insists these concepts apply to anything and everything. Which if your engineer you would probably disagree with. The potential exposure is increased significantly when not considering the development and implementation risks for any of these new technologies.

The Future

This project is currently under review and is the perfect opportunity for you to be heard on this topic. If you have an opinion on this standard please reach out to me. Does it work, does it not work. Especially, if you have worked in software development in startup or similar. Would like to understand your approach to development and what you consider the options for securing your products.

Well folks, we just completed 12 years at TwelveDot and it has been quite the ride for both the company and myself. We have had  a lot of changes over the years with both the company and how we operate. This was due to a changing focus with our customers and how we had approached offering our services. I would have never thought that I would get to meet so many new contacts, work in new sectors such as aviation, healthcare, and education, and get to travel the world over doing so. To all of our current and former clients thank-you for believing in us. To those we still have to meet, we look forward to the day we can satisfy your cyber needs.

Starting this month and going forward, I will be posting updates as we look to change some of the operational aspects of the business. These are not significant just changing with the times to again meet the demand of the market and need for specialized services.

I will also beginning a series on the CSA/ANSI T200 standard that was published last year. We were pivotal in both developing and writing this standard and we are hoping that it will really become a baseline for all IoT devices to be evaluated using a maturity model approach. This standard already is aligned to the ISO standard on a IoT baseline (ISO/IEC 27402) and the ETSI baseline (303 645) for Europe. We made harmonization a key aspect of this standard to allow vendors to get assessed under one program that would have global recognition. More on this later including the many organizations who are already recognizing this standard for testing and evaluation of IoT products.

I will also be announcing a book I am working on later this year as well. It represents the 10 plus years of work we have done for IoT both as research and as product evaluators.

With the post-COVID generation upon us, we look forward to contributing to more International standards work and projects that help to build on our recognized achievements to date. To our staff, this would not have happened without you and I am grateful for all our staff both current and previous.


This project started back in the Fall of 2016 in a boardroom in Seattle, Washington. The goal was to help a national utility company ensure that IoT based products were not weaponized while deployed. Their challenge to the team: How could a product assessment team help them given that there was national standards for things like a building code and electrical products.

Over the course of 18 months, a framework was created and validated using a pilot program with vendors who were considered SMBs in the IoT space. Several of these companies were only a few years old with very little in the way of process and procedure but were building a name for their products.

The program has three main phases:

    1. A self assessment;
    2. An audit based on claims made in the self-assessment, and;
    3. Formal testing (blackbox, white box, and grey box).

We were able to identify that most companies could complete the first phase in about 4 hours, the audit was typically completed in a day and testing was taking about one month. As the approach was not a “one-and-done” approach but a method to show maturity having a company enter the program would allow for the mapping of next target controls that need to be required.

This was how we started when we wrote the Expression version of T200, now fast forward 12 months and we have now added the following:

  • Add a baseline that maps to all international baselines for IoT based product companies;
  • Scope of testing is the solution not just the device;
  • Does not invalidate other programs or certifications already received for cyber but compliments them;
  • Created a supplement to deal with OT systems;
  • Defined the audit details that will be significant for both the auditor and organization being audited, and;
  • Providing a roadmap for young product companies to quickly map their current controls to those based on international standards and best practices to build maturity.

We believe that this standard will help SMBs who make products and services as it focuses not only on a product but how the company operates securely. This standard has been registered in both Canada (under Standards Council of Canada) and the United States (ANSI) so it will have applicability to many sectors including healthcare, OT, and automotive.

More information will be provided once the final version is published, which we anticipate in Spring of 2021. If you have any questions in the meantime please contact us.

The last few months have been hectic as many of the standards groups are pushing to get security and privacy aspects of IoT under control. As we get ready to whine down the year lets look at where we are:

a. ISO/IEC 27030 IoT Security and Privacy – This standard has now moved to Committee Draft (CD) and as the editor I am really proud of my editing team and global experts to get us her rather quickly. I believe this international standard will set the bar for IoT products globally and is highly anticipated by many groups and organizations globally.

b. ISO/IEC 27042 IoT Basline – This standard is currently a New Work Item Proposal (NWIP) and will be going to voting in the next few months. This is the result of a Adhoc Group that studied this and determined that we need a baseline for vendors who are entering the IoT product field. The goal is that this would be just a starting point and not the finish line for securing the product and organization but would provide regulators the guidance they need for products.

c. IoT Platform is group that has developed as result of work completed by the Internet Society in Canada. As a result of this work, a platform of regulators has formed and continues to expand how to ensure that IoT products are secure both now and in the future. As a result of this many nations will be making formal announcements to aspects that products should have. In Canada this has posted by Office of Consumer Affairs (OCA) and details are located here. I believe that this is good starting point but an hope that vendors will realized these aspects alone do not make a secure product that only happens when security and privacy become an embedded part of the organization and is driven into the development processes. I also hope that our regulators hold vendors to a higher sense of responsibility for security and products going forward.

d. CSA T200 has been released as an Express Standard and over the next 24 months we hope to develop the final version that will be used as the baseline for products and organizations in Canada and the US for meeting or exceeding regulatory requirements for IoT products. In the future we are looking for the implementation of a cyber label on products for security. More to come on this in the future.

e. IEC 30149 IoT Trustworthiness is still very much a work in progress as many experts are still trying to determine what consitutes trust. While one faction believes it is result of SDLC, I am very much of the opinion that this is not the case but view of the organization that includes the development processes. The approach must be based on an approach such as ISO 42010 that will allow any organization to determine the specific attributes to trust for their company and products being developed.

Here is the content for the IoT Checklist:

1. Ask how the device is collecting, using, and sharing your data

  • Is the device collecting my data? How is the device collecting my data?
  • Is the device using my data? How is the device using my data?
  • Is the device sharing my data? How is the device sharing my data?
  • With whom is the device sharing my data?
  • Is the device collecting data I do not want shared, such as my location?
  • Is there an option for me to opt out of the device collecting, sharing or using my data?
  • Will I be able to opt out of additional or future features that collect data, without opting out of security updates?

2. Ask about the device’s lifecycle, if it can function offline, and if there is product support available

  • How long can I expect the device to work?
  • How long are security patches and upgrades expected to be available for this product?
  • What kind of support is available should I experience problems with the device or suspect the device has been compromised?
  • Will the device work without an Internet connection? Can I use the product if the Internet is down? What features work offline?
  • Will the device work if the manufacturer ceases to exist?

3. Ask if the device you are buying is from a reputable manufacturer

  • Does the company have a good track record when it comes to protecting its customers’ privacy and security?
  • Check for media coverage online about whether or not this company has experienced a security breach in the past. If so, what was the impact on its consumers? What measures did the company take to prevent future security breaches?
  • Are there independent user reviews of the product I can consult?

For more tips on how to approach a business or manufacturer about your privacy and security concerns, check out this tip sheet.

Lots of progress this past year and lots more to come. I do see a shift that regulators globally are moving towards requirements for IoT companies. I hope it is a wake up call for vendors that due to the lack of security controls and the growing attack surface that IoT vendors will see a day where their products will undergo formal testing and evaluation to enter certain markets globally.


Yesterday, we officially launched CSA P125 Technical Committee on  Operational Technology Functional Safety and Security. This group is compromised of experts who represent organizations in multiple sectors and from both Canada and the United States. Our mandate is primary ensure that both international and regional standards of interest are adopted in both countries.

As our standards will be published under Standards Council of Canada (SCC) and American National Standards Institute (ANSI) they will recognized in both of these markets. As we look forward to providing both vendors and organizations options for selecting and implementing standards and certification options that will reflect a commitment to secure products and solutions by these vendors.

As the co-Chair to this group, I am very fortunate to be in such great company and expertise. As the editor of T200, I am humbled by the expertise we will have available to make our standard reflective of industry needs and requirements. I am looking forward to building relationships with the new members in the years ahead.

As with all new journeys, this one is even more special due to many of the critical aspects of the technologies we are dealing with. Getting to discuss so many new use cases and sectors it the best part of the job. There are so many cool projects and technologies that the layman just never sees but ensuring that many aspects of society continue to operate normally. This group is going to be there to set the bar for security in OT technology.



Over the past few months, we co-authored a CABA Whitepaper with BC Hydro’s David Rogers. The goal was to write a document that would help IoT vendors identify standards that should be considered for their IoT solutions and organization. As many buyers and procurement departments are developing requirements for products prior to evaluation and purchase ensuring that vendors, especially early stage companies, better understood the options is going to be key to adoption. With regulatory requirements being developed in many regions the future for products is going to mandate that several product categories undergo formal testing and evaluation. Getting ready for this is going to ease the transition, allow vendors to adapt to the frameworks and expand to new markets globally.

TwelveDot is honoured to have worked with staff of BC Hydro and others to develop this body of work and hope that SMB IoT vendors will benefit from our document and the approach to securing your operations and products. Also a shoutout to the folks at CSA Group for the support during this project. The funding was greatly appreciated.

The whitepaper can be found here:

At the recent IEC SC 41 Working Group and Plenary Meetings in Chongquin, CN. Our CEO and Convenor of AG 15 and AG 22 within SC41 presented at the Industry Workshop. It was well attended by government dignitaries, industry, local media and students.

Our presentation was focused on the testing and evaluation considerations for IoT products/solutions. This is based on the work we are doing with companies such as CSA Group for formal testing and evaluation and the development of a bi-national standard, T200, that reflects this need for product companies to have both a secure organization and products.

The goal is to have a cyber label on products for organizations who can demonstrate a security maturity. More details are contained in the presentation SC41 – TwelveDot_v1.


This past weekend, I was very fortunate to be the keynote speaker at the China-Canada IoT and Blockchain Innovation and Development Summit in Markham (Toronto). It was great to see so many attendees who are interested in IoT and Blockchain and the potential for how we might be able to address security and privacy in IoT.

With the announcement of the Canada China IoT and Blockhain Research Institute it will greatly help Canadian and China organizations who want to expand their reach for products/services in these regions and be able have a source for testing, evaluation and business development. We are proud to be part of this and we look forward to helping companies secure their IoT solutions.

As a proud member of SDChain, TwelveDot is looking forward to growing the SDChain network which is already at 120K users and counting. As we get closer to building the SDK’s and expanding our platform, trustworthiness is going to be key element of providing security and privacy to IoT product/service users globally.

As many of you have requested a copy of my presentation I am providing it here: SDChain Keynote_v1


With the recent rash of Healthcare data breaches it raises an important concern why is this happening? Especially, given the regulatory frameworks in place to protect patient data. We could spend many resources to determine the root cause of these issues however, there might be a better approach to begin with.

Specifically, healthcare providers, product and service companies need to change their approach to how they collect and protect patient data. The protection chain and data lifecycle needs to be completely understood. Only then can we ensure that data breaches do not become the norm.

TwelveDot using sound security principles based on ISO Security Standards has developed an organizational approach to addressing healthcare security. We have created a White Paper entitled “A Systematic Approach to Cyber Health” that details what organizations need to accomplish and our approach to put them in a position to better secure data handled.

Our goal is that only using a systematic approach to cyber security can healthcare providers ensure they protect their patient data.

Please download it here, and as usual please reach out to us with your questions, comments and issues in healthcare.


Starting next week Canada will be hosting the 3rd meeting of the WG 10 IoT in Ottawa.

These meeting are building towards the completion of ISO 30141 A Reference Architecture for IoT. We have many of the biggest companies, consortiums, special interest groups all in attendance. While, I am attending as an expert my focus is on the security and privacy elements of IoT. Over the summer,  I lead a SRG to develop the draft content for a Conceptual Reference Model (CRM) for this standard. While it is still a work in progress we are making significant strides on a base model.

I will provide more details next week once we begin our sessions and some details on what the major themes are.