Cisco Registered Envelope Service (CRES), big security flaw?

I'm actually the guy that invented the Cisco Registered Envelope. It was created in a startup called PostX originally. In the beginning we didn't do registration like that we made customer supply passwords for everyone. The problem is how do you do that if you are sending a message to someone outside your org (or someone you've never talked to before), I mean you could call them on the phone and say I'm making your password : xyz. Obviously, asymmetric/certificate based solutions solve that man in the middle problem, however, they have there own host of problems and complexities that they bring to the table. The original PostX product supported S/MIME, PGP, Secure WebMail portal, Envelopes using our SaaS key service, Envelopes using the customers database or LDAP system, Envelopes using a shared secret key that worked offline, and probably a few more embodiments.
Here's what it ended coming down to in the market. All of these different methods have their plusses and minuses. Sure, setting up S/MIME is super secure, but it's also complicated and requires a ton of pre-arrangement. The benefit of the Cisco Registered Envelope, is you could literally send an email to a new recipient and the appliance could detect that a possible HIPAA violation might be happening and automatically encrypt the message with a one time key and go ahead and send the encrypted message to the recipient before they have even registered. You are correct that if someone intercepts that first message, there will be problems, but you already have problems if someone is in your email. Ultimately, most companies realized that other encrypted email solutions were too complicated or required you to store the messages forever on a website, and the prevailing thinking was if it was too hard (like S/MIME) people would just send it in the clear. We basically used to say, there is a line with security on one end and ease of use on the other end and it just depends on where you want to live on that line. The great thing about CRES technology with the HIPAA lexicon, the sender literally has to do nothing to trigger encryption. If the words "reserve room 6 for surgery for Michael Johnson" show up in an email, and the customers has the HIPAA scanner turned on that email will get automatically encrypted. There is one final benefit of this model. With PostX/Cisco acting as the key warehouse, if you get CRES from multiple different companies, multiple senders - you use the same password with all of them because your password is between you and Cisco. A few more benefits : Each message has a unique key - which also allows you to retract a sent email by disabling that key. It also supports an anti-phishing pass-phrase that again is the same regardless what org is sending to you (you pick a phrase or word that shows up on the outside of the envelope, you don't see that phrase don't enter your password). Obviously, as the inventor I am a little biased, we had reasonable success with the product give how little people seem to care about encrypting email, and while it does have it's flaws we found that using something that was virtually painless with a few flaws was better than not using anything at all.

You have to start somewhere. Yes, it is possible for the initial introductory email to be hijacked, but this is true of many secure messaging systems.

In a perfect world, presumably step 3 would require the user to enter in information that would not be known to an attacker, such as a social security number, medical account number, date of birth, etc. This would be sufficient for confirming the identity during account setup.

That being said, it doesn't appear that Cisco CRES has that option, or if it does, it isn't normally used (I already found 2 banks that use CRES in the same way you described). Thus, I agree with you that if the initial email is intercepted, the security breaks down.